OK, ich habe eine ähnliche Schlussfolgerung wie Darren, obwohl sich der Profilierungsmechanismus geringfügig unterscheidet (Hinweis: Die langsame Anmeldung kann in Yosemite weiterhin auftreten).
Hier sehen Sie anhand des OS X- Beispielprofilerbefehls , was tatsächlich ausgeführt wird, wenn Sie ein neues Anmeldefenster starten .
Finden Sie heraus, welchen Befehl ein normaler Login ausführt
$ ps -ef | grep login
Du wirst so etwas sehen login -pfl username /bin/bash -c exec -la bash /bin/bash
Erstellen Sie einen Skriptdateinamen profile_login.shmit den folgenden Inhalten, indem Sie a hinzufügen
-c ""
bis zum Ende des erkannten Befehls, um die sofortige Rückgabe der Bash mit folgendem Inhalt anzufordern:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
Mach es ausführbar
$ chmod u+x profile_login.sh
und starte es mit sudo ( sampleBefehl benötigt es)
$ sudo ./profile_login.sh
OK, mach weiter und führe es aus. Zum Beispiel, indem Sie zuerst den purgeBefehl ausführen . Auf meiner Box habe ich eine große Ausgabekurve. Auf der Suche nach den "am größten nummerierten Zweigen" (normalerweise oben) sah ich die folgenden zwei größten Täter :
Eine von etwas namens, pam_startdie pam auth lib images zu öffnen scheint
+ ! 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]
und das wird manchmal von einem anderen Täter gefolgt 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]
Grundsätzlich gibt es also zwei Täter. Eines ist pam(irgendeine Art von Authentifizierungssystem) und das andere ist das asl"Erkennen Ihrer neuesten Anmeldedaten". Es reicht also anscheinend nicht aus, nur Ihre /private/var/log/asl/*.aslDateien zu löschen . Das Laden von PAM ist auf meinem Rechner ohnehin viel teurer [SSD]. Fühlen Sie sich frei, das obige Skript auszuführen und zu prüfen, ob Ihr System identisch ist. Interessanterweise scheint der Quellcode für diese Methodenaufrufe auch online verfügbar zu sein, zum Beispiel openpam_dynamic
Wenn ich der Antwort von Darren folge und meine "geöffneten Muscheln" durch etwas anderes als "/ bin / bash" ersetze, werden die folgenden Zeilen angezeigt, die zum Starten neuer Terminal-Registerkarten verwendet werden:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Also, wenn ich jetzt den gleichen sampleTrick auf den neuen Login-Befehl verwende
login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie
es wird ein viel kleinerer Stacktrace generiert, der größte Übeltäter ist:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
Ich denke, das liegt daran, dass der Login "-q" -Parameter jetzt verwendet wird. Anscheinend überspringt dieser Parameter sowohl das Laden der Pam-Module als auch das Nachschlagen der letzten Anmeldezeit (beide Täter). Laut den Dokumenten des loginBefehls sollte das Berühren der ~/.hushloginDatei dasselbe tun, aber anscheinend funktioniert dies nicht mehr [zumindest bei mir mit 10.10].
Zusammenfassend ist es also nicht ausreichend, /private/var/log/asl/*.asl zu entfernen (in meinem Experiment war dies nur für höchstens 1/3 der tatsächlichen Verlangsamung verantwortlich, wenn Sie dort mehr Dateien hätten, könnte dies jedoch eine Rolle spielen für einen größeren Prozentsatz bin ich mir sicher).
Wenn Sie ähnliche Skripte verwenden, sollten Sie in der Lage sein, zu ermitteln, warum Ihr lokaler Computer zum Stillstand gekommen ist, und zu prüfen, ob die oben genannte Korrektur auf Sie zutrifft. Fühlen Sie sich frei, hier zu kommentieren.
UPDATE: Es scheint, dass coresymbolication_load_imagedies auch beim login -pfqlAufrufen eine Menge Zeit in Anspruch nehmen kann (vermutlich muss sich ein Pam-Authentifizierungsmodul oder ein anderes Modul bei einem zentralen Anmeldeserver "auswählen" oder ein anderes, also muss es auf die Antwort eines Dritten warten ). Die einzige echte Problemumgehung, die ich gefunden habe, besteht darin, iTerm2 zu verwenden und stattdessen die Einstellungen -> Profile -> Allgemein -> Befehl auf zu ändern /bin/bash.
.bash_profile(siehe~/.profileübrigens auch). Beachten Sie auch, dass Sie mit der Eingabe beginnen können, während die Bash geladen wird. In der Regel wird das, was Sie eingeben, in die Eingabeaufforderung kopiert, sobald es fertig ist.