Come posso accelerare il tempo di caricamento della nuova scheda Terminale?


93

Come posso accelerare l'avvio del terminale in Lion?

Non mi riferisco all'avvio dell'applicazione Terminale, ma alle finestre del terminale di avvio, come quando apro una nuova scheda.

Non ho nulla nel mio file .bash_profile e corro rm -rf /private/var/log/asl/*.aslogni 4 ore (che cancella quei file che di solito rallentano il terminale).

Attualmente, quando apro una nuova scheda, ci vogliono 3-4 secondi prima di poter eseguire qualcosa.


2
Forse c'è qualcos'altro che non va nel tuo sistema? Non dovrebbe essere così lento. A volte ci vogliono un secondo o due per me, ma di solito è solo una frazione di secondo. E ho un bel po 'di tempo .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.
Abhi Beckert,

Stai utilizzando un account di rete o una home directory di rete? Il terminale risponde all'input dell'utente durante la creazione del terminale? Visualizza il cursore occupato che gira?
Chris Page

1
Per scoprire dove Terminal sta trascorrendo il tempo, apri Monitoraggio attività, seleziona Terminale e fai clic sul pulsante della barra degli strumenti Processo di esempio, quindi vai immediatamente a Terminale e crea una nuova finestra / scheda. Il campione può fornire un indizio su dove sta andando il tempo. Inoltre, guarda l'elenco dei processi in Activity Monitor: se "login" o "bash" (o qualunque shell tu stia utilizzando) appaiono nell'elenco durante il ritardo, ciò significa che probabilmente il ritardo si sta verificando in uno di quei due programmi e non Terminale.
Chris Page

Hai controllato la tua variabile PATH? Ho notato che il mio è stato assurdamente lungo con molte ripetizioni a causa di alcune confuse .bashrc in corso. Ho rimosso le ripetizioni e tutto ha accelerato!
190290000 Rublo uomo

Risposte:


93

Risposta breve:

Il problema è causato da una ricerca del registro di sistema ASL (potenzialmente) costosa. Per vederlo in azione, esegui sudo fs_usage | grep 'asl.*login'una finestra Terminale, quindi apri una nuova finestra Terminale.

Per risolvere il problema, configurare Terminal per avviare una shell non standard:

  1. Crea un collegamento simbolico alla tua shell preferita. Per esempio:sudo ln -s /bin/bash /usr/local/bin/bash
  2. Apri le Preferenze del terminale e seleziona la scheda "Generale".
  3. Seleziona "Conchiglie aperte con: Comando" e inserisci il collegamento simbolico creato nel passaggio 1. Ad esempio "/ usr / local / bin / bash".

Nota 1: Si può anche bisogno di aggiungere bashe -bashalla lista dei processi in "Terminal Preferenze> Profili> Shell> Chiedi prima di chiudere".

Nota 2: /usr/local/binè scrivibile in modalità Rootless OS X 10.11 (El Capitan).

Per verificare la correzione:

  • Apri una nuova finestra Terminale.
  • "Ultimo accesso:" non deve essere visualizzato in alto
  • Apri la finestra di ispezione (Comando + I) e seleziona la scheda Informazioni.
  • Il comando dovrebbe leggere login -pfq username /usr/bin/bashologin -pfql username ...

Importante: se il comando login non include il -qparametro, il problema non è stato risolto.

È inoltre possibile utilizzare sudo fs_usage | grep 'asl.*login'per verificare che /var/log/aslnon si accede quando si apre una nuova finestra Terminale.

Dettagli:

Ci sono molti bug in gioco qui.

La vera causa della lentezza è /usr/bin/loginche per impostazione predefinita visualizzerà la data dell'ultimo accesso. Per ottenere quest'ultima data di accesso, cerca nel database ASL (registro di sistema di Apple) all'indirizzo /var/log/asl/. Questi file di registro possono essere molto frammentati ed è questa frammentazione dei file che causa il ritardo all'apertura di una nuova finestra o scheda. (Bug 1)

L'unico modo per sopprimere la ricerca ASL per l'ultimo accesso è passare il -qparametro a /usr/bin/login. Il .hushloginfile eliminerà anche la schermata "Ultimo accesso", ma non sopprimerà la costosa ricerca ASL. (Bug 2)

Il terminale usa sempre /usr/bin/loginper avviare 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).

A quanto pare, Terminal passerà il -qparametro a /usr/bin/loginquando è configurato per utilizzare una shell non standard . (Bug 4)

Il -qparametro è ciò di cui abbiamo bisogno per evitare il problema, quindi il link simbolico a /usr/local/bin/bash.


6
Sai perché -q viene aggiunto se il comando è un collegamento simbolico a / bin / bash ma non se è / bin / bash?
Lri,

3
@LauriRanta Sembra essere un bug nel Terminale 10.7 e 10.8. Quando il comando di avvio è impostato, /bin/bashsi comporta come se fosse selezionata la Shell di accesso predefinita. Qualsiasi comando diverso da quello /bin/bashfunzionerà correttamente, quindi usare / usr / bin / bash è solo una soluzione alternativa. Questo errore non è presente in Snow Leopard.
Darren,

5
@Darren hai segnalato questo sospetto bug ad Apple? In caso contrario, potresti farlo tramite: bugreport.apple.com
Graham Miln,

3
Sfortunatamente, questo si traduce in un entusiasmo per l'esecuzione di bash ogni volta che chiudi il terminal su Yosemite. Quindi non è una bella soluzione :(
Claus Jørgensen il

2
@ ClausJørgensen Non ho riscontrato questo problema. Potresti voler controllare le impostazioni "Shell" nella scheda Profili.
Darren,

20

Ciò di cui avevo bisogno era passare dalla shell di accesso 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 variabili ambientali da~/.bash_profile


Che interrompe la ricerca di accesso di ASL secondo la domanda accettata
user151019

4
tra tutte le soluzioni, questa ha funzionato per me. +50!
Bhavin Doshi,

1
Grandi informazioni in questo thread! Questa è la soluzione che ho usato perché non richiedeva la creazione di symlink o altro. I miei nuovi tempi di avvio della shell sono passati da ~ 5-10 secondi all'istante con questa soluzione.
DustinB,

16

.hushlogin

Crea un file vuoto nella cartella home chiamato .hushlogin; questo ridurrà in modo significativo il tempo necessario per visualizzare una scheda Terminal.app.

Puoi creare il .hushloginfile in Terminal.app usando il seguente comando:

touch ~/.hushlogin

Il file avrà effetto immediato.

Puoi trovare ulteriori informazioni sul .hushloginfile e sulla procedura di accesso in generale nel manuale di accesso .

Silenziare il processo di accesso

Quando si crea una nuova scheda Terminale, si esegue la procedura di accesso. Il processo prevede il recupero di varie informazioni sulla sessione di accesso precedente, il messaggio del giorno e la visualizzazione dei messaggi di sistema. Questo può essere la fonte di ritardi significativi. Prova a mettere a tacere questi messaggi per vedere se il ritardo scompare.


6
.hushlogin non risolve effettivamente il problema. Questo può essere confermato usando opensnoop. Vedi la mia risposta qui sotto.
Darren,

1
@Darrren: man login mi dice: -q Questo impone login silenziosi, come se fosse presente un .hushlogin. L'opzione q è ciò che dici per evitare il problema, ma fa lo stesso che con hushlogin.
Christian,

8

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.


1
Oltre alla ricerca ASL, i ritardi nell'accesso sono spesso causati dalla connessione a una rete con un server di directory che risponde lentamente quando vengono richieste le informazioni dell'utente. Se non sei su una rete con i servizi di directory abilitati, non so cos'altro richiederebbe molto tempo, a parte la congestione generale del sistema (utilizzo della CPU, pressione della memoria, congestione I / O).
Chris Page

@ChrisPage Sì, probabilmente alcuni servizi di directory di rete qualcosa o altro, un buon consiglio.
rogerdpack,

3

Si tratta di indagare sulla causa. Puoi vedere cosa viene fatto mentre il processo inizia inserendo bash -xquale stampa 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 viene sempre da pensare che si tratti di spostare le pagine di memoria.


2

Riduci la tua cronologia a qualcosa tra 4 e 10 mila righe e forse prova a chiudere e a scartare tutte le finestre salvate. Ho visto entrambi fare la differenza su macchine più lente, specialmente quelle senza SSD per l'archiviazione.


2

Nel mio caso, dopo aver provato quanto sopra sulla mia macchina di lavoro senza successo, ho scoperto che il colpevole era Active Directory. La correzione consisteva nel accedere all'utilità Directory e modificare le impostazioni del servizio AD (fare doppio clic su "Active Directory") per abilitare "Crea account mobile all'accesso":

schermata dell'applicazione Directory Utility con le impostazioni di Active Directory aperte

Ciò apparentemente causa la memorizzazione nella cache locale delle credenziali di Active Directory, pertanto il sistema non deve più uscire dal server ogni volta che tenta di convalidare la password.

Puoi accedere a Directory Utility con Spotlight o tramite la sezione "Opzioni di accesso" di Preferenze di sistema / Utenti e gruppi (seleziona il pulsante "Modifica ..." accanto a "Server account di rete"):

Riquadro Utenti e gruppi che mostra "Opzioni di accesso" e "Modifica ..."


0

Corri:

sudo creatbyproc.d
sudo newproc.d

in terminali separati e apri il nuovo open per vedere cosa viene eseguito durante quel periodo.

Se nulla di ovvio, prova quanto segue:

sudo dtruss -an Terminal

In questo modo verranno stampati tutti i dettagli che si verificano nel tempo di caricamento della scheda.


0

Apri /etc/profilee aggiungi la linea PATH=""in questo modo:

if [ -x /usr/libexec/path_helper ]; then
    PATH=""
    eval `/usr/libexec/path_helper -s`
fi

0

Il problema per me era che il server di dominio di Active Directory non era valido.

Modificandolo e riavviando il mac è stato risolto.

inserisci qui la descrizione dell'immagine

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.