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.
.bash_profile(vérifiez aussi~/.profileau passage). Aussi: notez que vous pouvez commencer à taper pendant le chargement de bash, et ce que vous tapez sera généralement copié dans l'invite de commande une fois prêt.