Come posso velocizzare l'avvio del terminale in Lion?
Non mi riferisco all'avvio dell'applicazione Terminal, ma alle finestre del terminale di avvio, come quando apro una nuova scheda.
Non ho nulla nel mio file .bash_profile e eseguo rm -rf /private/var/log/asl/*.asl ogni 4 ore (che cancellano quei file che di solito rendono il terminale lento).
Attualmente, quando apro una nuova scheda, sono necessari 3-4 secondi per eseguire qualcosa.
Risposta breve:
Il problema è causato da una (potenzialmente) costosa ricerca del log di sistema ASL. Per vederlo in azione, esegui sudo fs_usage | grep 'asl.*login' in una finestra di Terminale, quindi apri una nuova finestra di Terminale.
Per risolvere il problema, configura Terminal per lanciare una shell non standard:
sudo ln -s /bin/bash /usr/local/bin/bash
Nota 1: potresti anche dover aggiungere bash e -bash all'elenco dei processi in "Preferenze Terminal > Profili > Shell > Chiedi prima di chiudere".
Nota 2: /usr/local/bin è scrivibile in OS X 10.11 (El Capitan) Modalità Rootless.
Per verificare la correzione:
login -pfq username /usr/bin/bash o login -pfql username ...
Importante: se il comando login non include il parametro -q , non hai risolto il problema.
Puoi anche usare sudo fs_usage | grep 'asl.*login' per verificare che /var/log/asl non sia accessibile quando apri una nuova finestra di Terminale.
Dettagli:
Ci sono un certo numero di bug in gioco qui.
La causa effettiva della lentezza è /usr/bin/login , che per impostazione predefinita visualizzerà la data dell'ultimo accesso. Per ottenere questa ultima data di accesso, cerca il database ASL (Apple System Log) su /var/log/asl/ . Questi file di registro possono essere molto frammentati e questa frammentazione dei file causa il ritardo durante l'apertura di una nuova finestra o scheda. (Bug 1)
L'unico modo per sopprimere la ricerca ASL per l'ultimo accesso è passare il parametro -q a /usr/bin/login . Il file .hushlogin sopprimerà anche la visualizzazione "Ultimo accesso", ma non sopprime la costosa ricerca ASL. (Bug 2)
Il terminale usa sempre /usr/bin/login per lanciare ogni nuova finestra / shell. Non esiste alcuna opzione per avviare direttamente una shell né esiste un modo per controllare direttamente i parametri passati a /usr/bin/login (Bug 3).
Come risulta, Terminal passerà il parametro -q a /usr/bin/login quando è configurato per utilizzare una shell non standard . (Bug 4)
Il parametro -q è ciò di cui abbiamo bisogno per evitare il problema, quindi il link simbolico a /usr/local/bin/bash .
Quello di cui avevo bisogno era cambiare dalla shell di login al comando /bin/bash -il
in Preferenze di iTerm > Profili > Generale > Comando .
Avevo bisogno dell'opzione -l ( Make bash act come se fosse stata invocata come shell di login ) aggiunta per impostare le variabili ambientali da ~/.bash_profile
Crea un file vuoto nella tua cartella home chiamata .hushlogin ; questo ridurrà significativamente il tempo necessario per la visualizzazione di una scheda Terminal.app.
Puoi creare il file .hushlogin in Terminal.app usando il seguente comando:
touch ~/.hushlogin
Il file avrà effetto immediatamente.
Puoi saperne di più sul file .hushlogin e sul processo di accesso in generale in manuale di accesso .
Quando crei una nuova scheda Terminale, stai attraversando il processo di accesso. Il processo comporta il recupero di varie informazioni sulla sessione di accesso precedente, il messaggio del giorno e la visualizzazione dei messaggi di sistema. Questa può essere la fonte di notevoli ritardi. Prova a mettere a tacere questi messaggi per vedere se il ritardo scompare.
OK Ho una conclusione simile a Darren, anche se un meccanismo di profilazione leggermente diverso (l'accesso lento NB può ancora verificarsi in Yosemite).
Ecco un modo per dire a che è effettivamente in esecuzione quando si avvia una nuova finestra di accesso, usando OS X esempio comando profiler.
Scopri quale comando esegue un normale login
$ ps -ef | grep login
Vedrai qualcosa come login -pfl username /bin/bash -c exec -la bash /bin/bash
Crea un nome file di script profile_login.sh con i seguenti contenuti aggiungendo un
-c ""
alla fine del comando rilevato per richiedere immediatamente il ritorno di bash, con contenuti come questo:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
Rendilo eseguibile
$ chmod u+x profile_login.sh
ed eseguirlo usando sudo (il comando sample lo richiede)
$ sudo ./profile_login.sh
OK, quindi vai avanti ed eseguilo. Ad esempio eseguendo prima il comando purge . Sulla mia scatola, ho ottenuto un grande grafico di output. Cercando i "più grandi rami numerati" (in genere nella parte superiore) ho visto i seguenti due principali autori di reati :
Uno da qualcosa chiamato pam_start che sembra aprire le immagini di auth lib di pam
+ ! 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 a volte viene seguito da un altro criminale 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 sostanzialmente, ci sono due trasgressori. Uno è pam (un certo tipo di sistema di autenticazione) e l'altro è asl "rileva il tuo ultimo accesso". Quindi apparentemente solo l'eliminazione dei file /private/var/log/asl/*.asl non è sufficiente. 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 al metodo sembra essere disponibile anche online, ad esempio openpam_dynamic
Se seguo la risposta di Darren e sostituisco la preferenza "shells open" con qualcosa di diverso da / bin / bash, allora vedo le seguenti linee usate per avviare nuove schede di terminale:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Quindi, se ora utilizzo lo stesso trucco sample 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 autore di reato è:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
Penso che questo sia dovuto al fatto che il parametro di login "-q" è ora in uso. Apparentemente questo parametro salta sia il caricamento dei moduli pam che durante la ricerca dell'ultimo tempo di accesso (entrambi i trasgressori). Secondo i documenti del comando login , toccare il file ~/.hushlogin dovrebbe fare la stessa cosa, ma a quanto pare questo non funziona più [almeno per me con 10.10].
Quindi, in sintesi, la rimozione di /private/var/log/asl/*.asl non è sufficiente (nel mio esperimento, ha rappresentato solo al massimo 1/3 del rallentamento effettivo, sebbene se ci fossero potrebbe rappresentare una percentuale maggiore ne sono sicuro).
Ad ogni modo usando script simili, dovresti essere in grado di dire cosa sta causando il riavvio della tua macchina locale, e vedere se la correzione sopra riportata si applica a te. Sentiti libero di commentare qui.
UPDATE: sembra che coresymbolication_load_image possa ancora richiedere un sacco di tempo, anche quando viene invocato login -pfql (presumibilmente qualche modulo di autenticazione pam o altro deve "chiamare" a un server di login centrale o qualcosa di strano, così ha aspettare una risposta da una terza parte). Quindi l'unica soluzione real che ho trovato è quella di usare iTerm2 e modificare le preferenze - > profili - > generale - > Comando su /bin/bash invece.
Si tratta di investigare la causa. Puoi vedere cosa si sta facendo mentre inizia il processo inserendo bash -x che stamperà il processo di avvio della shell.
Personalmente, noto solo il ritardo tra l'attivazione e la disattivazione dell'app e nella prima scheda creata dopo un periodo di attività. Mi fa sempre pensare che si tratti di spostare le pagine di memoria.
Riduci la cronologia su un valore compreso tra 4 e 10 mila righe e forse prova a uscire e a ignorare tutte le finestre salvate. Ho visto entrambi fare la differenza su macchine più lente - specialmente quelle senza SSD per l'archiviazione.
Nel mio caso, dopo aver provato sopra sulla mia macchina da lavoro senza successo, ho scoperto che il colpevole era Active Directory. La soluzione era quella di accedere a Utility Directory e modificare le impostazioni del servizio AD (fai doppio clic su "Active Directory") per abilitare "Crea account mobile all'accesso":
Aquantopare,lecredenzialiADvengonomemorizzatenellacachealivellolocale,quindiilsistemanondevepiùusciresulserverognivoltachetentadiconvalidarelapassword.
PuoiaccedereaDirectoryUtilityconSpotlightotramitelasezione"Opzioni di accesso" di Preferenze di Sistema / Utenti & Gruppi (selezionare il pulsante "Modifica ..." accanto a "Server account di rete"):
Esegui:
sudo creatbyproc.d
sudo newproc.d
in terminali separati e apri il nuovo open per vedere cosa viene eseguito in quel momento.
Se non è ovvio, prova quanto segue:
sudo dtruss -an Terminal
Questo stamperà tutti i tuoi dettagli che si verificano durante il caricamento della scheda.
Apri /etc/profile e aggiungi la riga PATH="" in modo che assomigli a questa:
if [ -x /usr/libexec/path_helper ]; then
PATH=""
eval '/usr/libexec/path_helper -s'
fi
Il problema per me era che il server di dominio delle directory attivo non era valido.
Cambiandolo, riavvialo il Mac.
Leggi altre domande sui tag command-line macos terminal