Comment puis-je accélérer le démarrage du terminal dans Lion?

Je ne fais pas référence au démarrage de l'application Terminal, mais aux fenêtres de démarrage du terminal, comme lorsque j'ouvre un nouvel onglet.

Je n'ai rien dans mon fichier .bash_profile et je lance rm -rf /private/var/log/asl/*.asltoutes les 4 heures (ce qui efface ces fichiers qui rendent généralement le terminal lent).

Actuellement, quand j'ouvre un nouvel onglet, il faut 3-4 secondes pour que je puisse exécuter quelque chose.

Réponse courte:

Le problème est dû à une recherche (potentiellement) coûteuse du journal système ASL. Pour voir cela en action, exécutez-le sudo fs_usage | grep 'asl.*login'dans une fenêtre de terminal, puis ouvrez une nouvelle fenêtre de terminal.

Pour résoudre le problème, configurez Terminal pour lancer un shell non standard:

1. Créez un lien symbolique vers votre shell préféré. Par exemple:sudo ln -s /bin/bash /usr/local/bin/bash
2. Ouvrez les préférences du terminal et sélectionnez l'onglet "Général".
3. Sélectionnez "Shells open with: Command" et entrez le lien symbolique créé à l'étape 1. Par exemple, "/ usr / local / bin / bash".

Remarque 1: Vous devrez peut-être aussi ajouter bashet -bashà la liste des processus dans "Préférences de terminal> Profils> Shell> Demander avant de fermer".

Remarque 2: /usr/local/binest accessible en écriture sous le mode sans racine OS X 10.11 (El Capitan).

Pour vérifier le correctif:

• Ouvrez une nouvelle fenêtre de terminal.
• "Dernière connexion:" ne doit pas être affiché en haut
• Ouvrez l'inspecteur (Commande + I) et sélectionnez l'onglet Info.
• La commande devrait lire login -pfq username /usr/bin/bashoulogin -pfql username ...

Important: Si la commande de connexion n'inclut pas le -qparamètre, vous n'avez pas résolu le problème.

Vous pouvez également sudo fs_usage | grep 'asl.*login'vérifier que l’ /var/log/aslaccès n’est pas activé lors de l’ouverture d’une nouvelle fenêtre de terminal.

Détails:

Il y a un certain nombre de bugs en jeu ici.

La cause réelle de la lenteur est /usr/bin/login, qui par défaut affichera la date de votre dernière connexion. Pour obtenir cette dernière date de connexion, il effectue une recherche dans la base de données ASL (Apple System Log) à l'adresse /var/log/asl/. Ces fichiers journaux peuvent être très fragmentés et c'est cette fragmentation qui cause le retard lors de l'ouverture d'une nouvelle fenêtre ou d'un nouvel onglet. (Bug 1)

La seule façon de supprimer la recherche ASL pour la dernière connexion consiste à transmettre le -qparamètre à /usr/bin/login. Le .hushloginfichier supprimera également l'affichage "Dernière connexion", mais pas la recherche coûteuse ASL. (Bug 2)

Terminal utilise toujours /usr/bin/loginpour lancer chaque nouvelle fenêtre / shell. Il n’existe aucune option permettant de lancer directement un shell, ni un moyen de contrôler directement les paramètres transmis à /usr/bin/login(bogue 3).

En fin de compte, Terminal transmettra le -qparamètre à /usr/bin/loginlorsqu'il sera configuré pour utiliser un shell non standard . (Bug 4)

Le -qparamètre est ce dont nous avons besoin pour éviter le problème, d’où le lien symbolique vers /usr/local/bin/bash.

Ce dont j'avais besoin, c'était de passer du shell de connexion à la commande /bin/bash -il dans Préférences> Profils> Général> Commande d' iTerm .

J'avais besoin de l'option -l( Make bash agit comme si elle avait été invoquée en tant que shell de connexion ), afin de définir les variables d'environnement de~/.bash_profile

.hushlogin

Créez un fichier vide dans votre dossier personnel appelé .hushlogin; cela réduira considérablement le temps nécessaire pour qu'un onglet Terminal.app apparaisse.

Vous pouvez créer le .hushloginfichier dans Terminal.app à l'aide de la commande suivante:

touch ~/.hushlogin

Le fichier prendra effet immédiatement.

Vous pouvez en apprendre plus sur le .hushloginfichier et le processus de connexion en général dans le manuel de connexion .

Calmer le processus de connexion

Lorsque vous créez un nouvel onglet Terminal, vous suivez le processus de connexion. Le processus consiste à récupérer diverses informations sur votre session de connexion précédente, le message du jour et l'affichage des messages système. Cela peut être la source de retards importants. Essayez de faire taire ces messages pour voir si le délai disparaît.

OK, j'ai une conclusion similaire à celle de Darren, bien que le mécanisme de profilage soit légèrement différent (NB: une connexion lente peut encore se produire dans Yosemite).

Voici un moyen de savoir ce qui est en cours d’exécution lorsque vous ouvrez une nouvelle fenêtre de connexion à l’aide de la commande exemple de profileur OS X.

Découvrez quelle commande un exécutant de connexion normale

$ ps -ef | grep login

Vous verrez quelque chose comme login -pfl username /bin/bash -c exec -la bash /bin/bash

Créez un nom de fichier de script profile_login.shavec le contenu suivant en ajoutant un

-c ""

à la fin de la commande discovery pour demander que bash retourne immédiatement, avec un contenu comme celui-ci:

login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command

Le rendre exécutable

$ chmod u+x profile_login.sh

et l'exécuter en utilisant sudo (la samplecommande le requiert)

$ sudo ./profile_login.sh

OK alors allez-y et lancez-le. Par exemple, en exécutant d'abord la purgecommande. Sur ma boîte, j'ai un grand graphique de sortie. À la recherche des "plus grandes succursales numérotées" (généralement en haut), j'ai vu les deux plus grands délinquants suivants :

Un de quelque chose appelé pam_startqui apparaît à l'ouverture des images pam auth lib

+   ! 1068 pam_start  (in libpam.2.dylib) + 132  [0x7fff97295ab0]
+   !    :   1066 openpam_dynamic  (in libpam.2.dylib) + 120  [0x7fff97293d14]
+   !    :   |   +   !   1042 coresymbolication_load_image(CSCppDyldSharedMemoryPage*, ImageLoader const*, unsigned long long)  (in dyld) + 143  [0x7fff66725411]
+   !    :   |   +   !   :     1042 mach_msg_trap  (in dyld) + 10  [0x7fff6674a472]

et qui est parfois suivi par un autre délinquant getlastlogxbyname

+   ! 583 getlastlogxbyname  (in libsystem_c.dylib) + 212  [0x7fff92b3ef7a]
+   !       : 566 asl_file_open_read  (in libsystem_asl.dylib) + 143  [0x7fff8c27030d]
+   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]    +   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]

Donc, fondamentalement, il y a deux délinquants. L'un est pam(un type de système d'authentification) et l'autre il asl"détecte votre dernier login". Donc , apparemment simplement supprimer vos /private/var/log/asl/*.aslfichiers ne suffit pas. Le chargement de pam est beaucoup plus cher sur ma machine, de toute façon [SSD]. N'hésitez pas à exécuter le script ci-dessus et à voir si votre système est identique. Fait intéressant, le code source de ces appels de méthode semble également être disponible en ligne, par exemple openpam_dynamic

Si je suis la réponse de Darren et remplace mes préférences "shell ouvert" par une préférence autre que / bin / bash, je vois les lignes suivantes utilisées pour démarrer les nouveaux onglets de terminal:

 $ ps -ef | grep login
  ... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash

Donc, si j'utilise maintenant le même sampletruc sur la nouvelle commande de connexion

login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie

un stacktrace beaucoup plus petit est généré, le plus grand contrevenant étant:

+         8 pam_end  (in libpam.2.dylib) + 190  [0x7fff97294ebb]
+             !           6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*)  (in dyld) + 143  [0x7fff6e0f634f]

Je pense que cela est dû au fait que le paramètre de connexion "-q" est maintenant utilisé. Apparemment, ce paramètre ignore le chargement des modules de pam et la recherche de la dernière heure de connexion (les deux délinquants). Selon la documentation de la logincommande, toucher le ~/.hushloginfichier devrait faire la même chose, mais apparemment cela ne fonctionne plus [du moins pour moi avec 10.10].

Donc, en résumé, supprimer /private/var/log/asl/*.asl n’est pas suffisant (dans mon expérience, cela ne représentait qu’un tiers au maximum du ralentissement réel, bien que si vous y aviez des fichiers plus volumineux, cela pourrait expliquer pour un plus grand pourcentage j'en suis sûr).

Quoi qu'il en soit, en utilisant des scripts similaires, vous devriez être capable de dire ce qui cause le blocage de votre machine locale et de voir si le correctif ci-dessus vous concerne. N'hésitez pas à commenter ici.

UPDATE: semble que cela coresymbolication_load_imagepeut encore prendre des tonnes de temps, même quand login -pfqlest invoqué (vraisemblablement un module d'authentification pam ou autre est obligé de "composer un numéro" avec un serveur de connexion central ou quelque chose de bizarre, donc d'attendre une réponse d'un tiers ). La seule vraie solution que j'ai trouvé est d'utiliser iTerm2 et modifier les préférences -> Profils -> Général -> Commande à la /bin/bashplace.

Il s’agit d’enquêter sur la cause. Vous pouvez voir ce qui se fait pendant que le processus commence en indiquant bash -xqui imprimera le processus de démarrage du shell.

Personnellement, je ne remarque que le délai entre l'activation et la désactivation de l'application et dans le premier onglet créé après une période d'activité. Cela me fait toujours penser qu'il s'agit de déplacer des pages de mémoire.

Réduisez votre historique à quelque 4 000 à 10 000 lignes et essayez peut-être de quitter et de supprimer toutes les fenêtres enregistrées. J'ai vu les deux faire la différence sur des machines plus lentes, en particulier celles sans disque SSD pour le stockage.

Dans mon cas, après avoir essayé ce qui précède sur ma machine de travail sans succès, j'ai découvert que le coupable était Active Directory. Le correctif consistait à accéder à Directory Utility et à modifier les paramètres du service AD ​​(double-cliquez sur "Active Directory") pour activer "Créer un compte mobile à la connexion":

Cela entraîne apparemment la mise en cache locale des informations d'identification AD, de sorte que le système n'a plus besoin de se connecter au serveur à chaque fois qu'il tente de valider votre mot de passe.

Vous pouvez accéder à Directory Utility avec Spotlight ou via la section "Options de connexion" des Préférences Système / Utilisateurs et groupes (sélectionnez le bouton "Modifier ..." en regard de "Serveur de compte réseau"):

Il suffit de courir:

sudo creatbyproc.d
sudo newproc.d

dans des terminaux séparés et ouvrez la nouvelle ouverture pour voir ce qui est exécuté pendant ce temps.

Si rien d’évident, essayez ce qui suit:

sudo dtruss -an Terminal

Ceci imprimera toutes vos informations sur le temps de chargement des onglets.

Ouvrez /etc/profileet ajoutez la ligne PATH=""afin qu'elle ressemble à ceci:

if [ -x /usr/libexec/path_helper ]; then
    PATH=""
    eval `/usr/libexec/path_helper -s`
fi

Le problème pour moi était que le serveur de domaine Active Directory n'était pas valide.

Le changer puis redémarrer le mac l'a corrigé.