Réponse courte :

Le problème est causé par une consultation (potentiellement) coûteuse du journal du système ASL. Pour voir cela en action, exécutez sudo fs_usage | grep 'asl.*login' dans une fenêtre du Terminal, puis ouvrez une nouvelle fenêtre du 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 que vous avez créé à l'étape 1. Par exemple, "/usr/local/bin/bash".

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

Note 2 : /usr/local/bin est accessible en écriture dans le mode Rootless de OS X 10.11 (El Capitan).

Pour vérifier la correction :

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

Important : Si la commande de connexion ne comprend pas l'option -q vous n'avez pas résolu le problème.

Vous pouvez également utiliser sudo fs_usage | grep 'asl.*login' pour vérifier que /var/log/asl n'est pas accessible 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, affiche la date de votre dernière connexion. Pour obtenir cette date, il effectue une recherche dans la base de données ASL (Apple System Log) à l'adresse suivante /var/log/asl/ . Ces fichiers journaux peuvent être très fragmentés et c'est cette fragmentation des fichiers qui provoque 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 le dernier login est de passer l'option -q pour /usr/bin/login . Le site .hushlogin supprimera également l'affichage de la "Dernière connexion", mais il ne supprime pas la recherche ASL coûteuse. (Bug 2)

Le terminal utilise toujours /usr/bin/login pour lancer chaque nouvelle fenêtre/shell. Il n'y a pas d'option pour lancer directement un shell, ni de moyen de contrôler directement les paramètres passés à l'option /usr/bin/login (Bug 3).

Il s'avère que le terminal passera le -q pour /usr/bin/login lorsqu'il est configuré pour utiliser un hors normes coquille. (Bug 4)

El -q 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 était de passer du shell de connexion à la commande /bin/bash -il dans l'iTerm Préférences > Profils > Général > Commande .

J'avais besoin de l'option -l ( Faire en sorte que bash se comporte comme s'il avait été invoqué comme un shell de connexion ) ajouté afin de définir les variables environnementales de ~/.bash_profile

.hushlogin

Créez un fichier vide dans votre dossier personnel appelé .hushlogin ; cela réduira considérablement le temps nécessaire à l'apparition d'un onglet de Terminal.app.

Vous pouvez créer le .hushlogin dans Terminal.app en utilisant la commande suivante :

touch ~/.hushlogin

Le dossier prendra effet immédiatement.

Vous pouvez en savoir plus sur le .hushlogin et le processus de connexion en général dans le fichier manuel de connexion .

Rendre le processus de connexion plus silencieux

Lorsque vous créez un nouvel onglet du terminal, vous passez par le processus de connexion. Ce processus implique la récupération de diverses informations sur votre précédente session de connexion, le message du jour et l'affichage de messages système. Cela peut être à l'origine de retards importants. Essayez de masquer 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 : la connexion lente peut toujours se produire dans Yosemite).

Voici un moyen de savoir ce que est en cours d'exécution lorsque vous démarrez une nouvelle fenêtre de connexion, en utilisant la fonction OS X échantillon commande de profilage.

Découvrez quelle commande exécute un login normal

$ ps -ef | grep login

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

Créer un nom de fichier . profile_login.sh avec le contenu suivant en ajoutant un

-c ""

à la fin de la commande découverte pour demander à bash de revenir 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

Rendez-le exécutable

$ chmod u+x profile_login.sh

et l'exécuter en utilisant sudo ( sample l'exige)

$ sudo ./profile_login.sh

OK, alors allez-y et lancez-la. Par exemple en exécutant le purge d'abord. Sur ma boîte, j'ai obtenu un grand graphique de sortie. En cherchant les "branches numérotées les plus importantes" (généralement en haut), j'ai vu les deux suivantes principaux contrevenants :

Un de quelque chose appelé pam_start qui semble ouvrir les images de la librairie pam auth

+   ! 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 d'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, en gros, il y a deux délinquants. L'un est pam (un certain type de système d'authentification) et l'autre le asl "détecter votre dernière connexion". Donc apparemment juste en supprimant votre /private/var/log/asl/*.asl ne suffit pas. Le chargement de la pam est beaucoup plus cher sur ma machine, de toute façon [SSD]. N'hésitez pas à exécuter le script ci-dessus et voyez si votre système est le même. Il est intéressant de noter que le code source de ces appels de méthode semble également être disponible en ligne, par exemple openpam_dynamique

Si je suis la réponse de Darren, et que je remplace ma préférence "shells open with" par autre chose que /bin/bash, je vois alors les lignes suivantes utilisées pour démarrer de 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 sample astuce 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 délinquant étant :

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

Je pense que c'est parce que le paramètre "-q" de connexion est maintenant utilisé. Apparemment, ce paramètre ignore le chargement des deux modules pam. et en recherchant la dernière heure de connexion (pour les deux délinquants). Selon les docs du login en touchant la commande ~/.hushlogin devrait faire la même chose, mais apparemment cela ne fonctionne plus [du moins pour moi avec la 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'au maximum 1/3 du ralentissement réel, bien que si vous aviez des fichiers mores à cet endroit, cela pourrait représenter un plus grand pourcentage, j'en suis sûr).

Quoi qu'il en soit, en utilisant des scripts similaires, vous devriez être en mesure de dire ce qui cause l'embouteillage de votre machine locale, et voir si la correction ci-dessus s'applique à vous. N'hésitez pas à commenter ici.

UPDATE : il semble que coresymbolication_load_image peut toujours prendre beaucoup de temps, même si login -pfql est invoquée (on suppose qu'un module d'authentification Pam ou autre doit se connecter à un serveur de connexion central ou autre, et doit donc attendre une réponse d'une tierce partie). Ainsi, la seule réel La solution que j'ai trouvée est d'utiliser iTerm2, et de changer les préférences -> profils -> général -> Commande en /bin/bash à la place.

Il s'agit de rechercher la cause. Vous pouvez voir ce qui est fait pendant que le processus démarre en entrant bash -x qui 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 pages de mémoire qui sont déplacées.