OK, ho una conclusione simile a Darren, sebbene un meccanismo di profilazione leggermente diverso (NB, in Yosemite può ancora verificarsi un accesso lento).
Ecco un modo per sapere cosa è effettivamente in esecuzione quando si avvia una nuova finestra di accesso, utilizzando il comando di profiler di esempio di OS X.
Scopri quale comando esegue un normale accesso
$ ps -ef | grep login
Vedrai qualcosa di simile login -pfl username /bin/bash -c exec -la bash /bin/bash
Creare un nome file di script profile_login.shcon i seguenti contenuti aggiungendo a
-c ""
alla fine del comando rilevato per richiedere che bash ritorni immediatamente, con contenuti come questo:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
Renderlo eseguibile
$ chmod u+x profile_login.sh
ed eseguirlo usando sudo (il samplecomando lo richiede)
$ sudo ./profile_login.sh
OK quindi vai avanti ed eseguilo. Ad esempio eseguendo purgeprima il comando. Sulla mia scatola, ho un grande grafico di output. Alla ricerca dei "più grandi rami numerati" (in genere in alto) ho visto i seguenti due più grandi criminali :
Uno da qualcosa chiamato pam_startche sembra aprire le immagini di 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]
e che a volte è seguito da un altro colpevole 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]
Quindi, in sostanza, ci sono due criminali. Uno è pam(un tipo di sistema di autenticazione) e l'altro è l' aslelemento "rileva il tuo ultimo accesso". Quindi apparentemente solo eliminare i tuoi /private/var/log/asl/*.aslfile non è abbastanza. Il caricamento del pam è molto più costoso sulla mia macchina, comunque [SSD]. Sentiti libero di eseguire lo script sopra e vedere se il tuo sistema è lo stesso. È interessante notare che il codice sorgente per queste chiamate di metodo sembra essere disponibile anche online, ad esempio openpam_dynamic
Se seguo la risposta di Darren e rimpiazzo la mia preferenza "shells open with" con qualcosa di diverso da / bin / bash, vedo le seguenti righe utilizzate per avviare nuove schede terminali:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Quindi, se ora uso lo stesso sampletrucco sul nuovo comando di accesso
login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie
viene generato uno stacktrace molto più piccolo, il più grande delinquente è:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
Penso che questo sia perché il parametro di accesso "-q" è ora in uso. Apparentemente questo parametro salta sia il caricamento dei moduli pam che la ricerca dell'ultimo tempo di accesso (entrambi i trasgressori). Secondo i documenti del logincomando, toccare il ~/.hushloginfile dovrebbe fare la stessa cosa, ma a quanto pare non funziona più [almeno per me con 10.10].
Quindi, in sintesi, rimuovere /private/var/log/asl/*.asl non è abbastanza (nel mio esperimento, ha rappresentato solo al massimo 1/3 del rallentamento effettivo, anche se se avessi file mores lì potrebbe tenere conto per una percentuale maggiore ne sono sicuro).
In ogni caso, usando script simili, dovresti essere in grado di dire cosa sta causando l'arresto del tuo computer locale e vedere se la correzione di cui sopra si applica a te. Sentiti libero di commentare qui.
AGGIORNAMENTO: sembra che coresymbolication_load_imagepossa ancora richiedere parecchio tempo, anche quando login -pfqlviene invocato (presumibilmente un modulo di autenticazione pam o altro deve "chiamare" un server di accesso centrale o qualche dispari, quindi deve attendere una risposta da una terza parte ). Quindi l'unica vera soluzione che ho trovato è usare iTerm2 e modificare invece le preferenze -> profili -> generali -> Comando /bin/bash.
.bash_profile(controlla anche~/.profilea proposito). Inoltre: nota che puoi iniziare a digitare mentre bash sta caricando, e di solito ciò che scrivi verrà copiato al prompt dei comandi una volta pronto.