Como acelerar o novo tempo de carregamento da guia Terminal?


93

Como acelerar a inicialização do terminal no Lion?

Não estou me referindo à inicialização do aplicativo Terminal, mas às janelas do terminal de inicialização, como quando abro uma nova guia.

Não tenho nada no meu arquivo .bash_profile e corro a rm -rf /private/var/log/asl/*.aslcada 4 horas (que limpa os arquivos que normalmente tornam o terminal lento).

Atualmente, quando abro uma nova guia, leva de 3 a 4 segundos até que eu possa executar alguma coisa.


2
Talvez haja algo de errado com o seu sistema? Não deve ser tão lento. Às vezes, leva um ou dois segundos para mim, mas geralmente é apenas uma fração de segundo. E eu tenho um pouco de bom senso .bash_profile(também verifique ~/.profilea propósito). Além disso: observe que você pode começar a digitar enquanto o bash está carregando e, geralmente, o que você digita será copiado no prompt de comando quando estiver pronto.
Abhi Beckert

Você está usando uma conta de rede ou um diretório inicial da rede? O Terminal responde à entrada do usuário enquanto cria o terminal? Ele exibe o cursor ocupado girando?
31412 Chris Page

1
Para descobrir onde o Terminal está gastando tempo, abra o Monitor de Atividade, selecione Terminal e clique no botão da barra de ferramentas Processo de Amostra; em seguida, vá imediatamente para o Terminal e crie uma nova janela / guia. A amostra pode fornecer uma pista para onde está indo o tempo. Além disso, observe a lista de processos no Activity Monitor: se "login" ou "bash" (ou qualquer shell que você estiver usando) aparecer na lista durante o atraso, isso significa que o atraso provavelmente está ocorrendo em um desses dois programas e não Terminal.
31412 Chris Page

Você verificou sua variável PATH? Percebi que o meu era absurdamente longo com muitas repetições devido a algumas coisas confusas do .bashrc. Tirei as repetições e tudo acelerou!
190290000 Ruble Man

Respostas:


93

Resposta curta:

O problema é causado por uma pesquisa de log do sistema ASL (potencialmente) cara. Para ver isso em ação, execute sudo fs_usage | grep 'asl.*login'em uma janela do Terminal e abra uma nova janela do Terminal.

Para resolver o problema, configure o Terminal para iniciar um shell não padrão:

  1. Crie um link simbólico para o seu shell preferido. Por exemplo:sudo ln -s /bin/bash /usr/local/bin/bash
  2. Abra Preferências do terminal e selecione a guia "Geral".
  3. Selecione "Shells abertos com: Command" e digite o link simbólico criado na etapa 1. Por exemplo, "/ usr / local / bin / bash".

Nota 1: Você também pode precisar adicionar bashe -bashà lista de processos em "Preferências do terminal> Perfis> Shell> Perguntar antes de fechar".

Nota 2: /usr/local/biné gravável no modo sem raiz do OS X 10.11 (El Capitan).

Para verificar a correção:

  • Abra uma nova janela do Terminal.
  • "Último login:" não deve ser exibido na parte superior
  • Abra o inspetor (Command + I) e selecione a guia Informações.
  • O comando deve ler login -pfq username /usr/bin/bashoulogin -pfql username ...

Importante: Se o comando login não incluir o -qparâmetro, você não resolveu o problema.

Você também pode usar sudo fs_usage | grep 'asl.*login'para verificar /var/log/aslse não é acessado ao abrir uma nova janela do Terminal.

Detalhes:

Há vários bugs em jogo aqui.

A causa real da lentidão é a /usr/bin/loginque, por padrão, exibirá a data do seu último login. Para obter essa última data de login, ele pesquisa no banco de dados ASL (Apple System Log) em /var/log/asl/. Esses arquivos de log podem ser muito fragmentados e é essa fragmentação que causa o atraso ao abrir uma nova janela ou guia. (Bug 1)

A única maneira de suprimir a busca ASL por último login é passar o -qparâmetro para /usr/bin/login. O .hushloginarquivo também suprimirá a exibição "Último login", mas não suprimirá a pesquisa cara de ASL. (Bug 2)

O terminal sempre usa /usr/bin/loginpara iniciar cada nova janela / shell. Não há opção para iniciar um shell diretamente nem existe uma maneira de controlar diretamente os parâmetros passados ​​para /usr/bin/login(Bug 3).

Como se vê, o Terminal passará o -qparâmetro para /usr/bin/loginquando estiver configurado para usar um shell não padrão . (Bug 4)

O -qparâmetro é o que precisamos para evitar o problema, daí o link simbólico para /usr/local/bin/bash.


6
Você sabe por que -q é adicionado se o comando é um link simbólico para / bin / bash, mas não se é / bin / bash?
Lr 18/12 /

3
@LauriRanta Parece ser um bug no Terminal 10.7 e 10.8. Quando o comando de inicialização é definido, /bin/bashele se comporta como se o Shell de Login Padrão estivesse selecionado. Qualquer comando que /bin/bashnão funcione corretamente, portanto, usar / usr / bin / bash é apenas uma solução alternativa. Este bug não está presente no Snow Leopard.
Darren

5
@ Darren, você relatou esse bug suspeito à Apple? Caso contrário, você pode fazê-lo através de: bugreport.apple.com
Graham Miln 31/12/12

3
Infelizmente, isso resulta em um alerta sobre a execução do bash toda vez que você fecha o terminal em Yosemite. Então não é uma boa solução :(
Claus Jørgensen

2
@ ClausJørgensen Não tive esse problema. Convém verificar as configurações de "Shell" na guia Perfis.
Darren

20

O que eu precisava era mudar do shell de login para o comando /bin/bash -il em Preferências do iTerm > Perfis> Geral> Comando .

Eu precisava da opção -l( Fazer o bash agir como se tivesse sido chamado como um shell de login ) adicionada para definir variáveis ​​ambientais de~/.bash_profile


Que pára a busca de login do ASL como pela questão aceito
user151019

4
de todas as soluções, essa funcionou para mim. +50!
Bhavin Doshi

1
Ótimas informações em todo este segmento! Esta é a solução que usei porque não exigia a criação de links simbólicos ou algo assim. Meus novos tempos de inicialização do shell passaram de ~ 5 a 10 segundos para instantes com esta solução.
DustinB 22/11/2015

16

.hushlogin

Crie um arquivo vazio na sua pasta pessoal chamada .hushlogin; isso diminuirá significativamente o tempo necessário para que uma guia Terminal.app apareça.

Você pode criar o .hushloginarquivo no Terminal.app usando o seguinte comando:

touch ~/.hushlogin

O arquivo entrará em vigor imediatamente.

Você pode aprender mais sobre o .hushloginarquivo e o processo de login em geral no manual de login .

Silenciando o processo de login

Ao criar uma nova guia Terminal, você está passando pelo processo de login. O processo envolve buscar várias informações sobre sua sessão de login anterior, mensagem do dia e exibir mensagens do sistema. Isso pode ser a fonte de atrasos significativos. Tente ocultar essas mensagens para ver se o atraso desaparece.


6
.hushlogin não resolve o problema. Isso pode ser confirmado usando opensnoop. Veja minha resposta abaixo.
Darren

1
@Darrren: man login me diz: -q Isso força logins silenciosos, como se um .hushlogin estivesse presente. A opção q é o que você diz que evita o problema, mas faz o mesmo que com o hushlogin.
Christian

8

OK. Eu tenho uma conclusão semelhante a Darren, embora o mecanismo de criação de perfil seja ligeiramente diferente (o login lento do NB ainda pode ocorrer em Yosemite).

Aqui está uma maneira de saber o que realmente está em execução quando você inicia uma nova janela de login, usando o comando OS X sample profiler.

Descubra qual comando um logon normal executa

$ ps -ef | grep login

Você verá algo como login -pfl username /bin/bash -c exec -la bash /bin/bash

Crie um nome de arquivo de script profile_login.shcom o seguinte conteúdo adicionando um

-c ""

até o final do comando descoberto para solicitar que o bash retorne imediatamente, com conteúdo como este:

login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command

Torne executável

$ chmod u+x profile_login.sh

e execute-o usando o sudo (o samplecomando exige)

$ sudo ./profile_login.sh

OK, então vá em frente e execute-o. Por exemplo, executando o purgecomando primeiro. Na minha caixa, recebi um grande gráfico de saída. Procurando pelos "maiores ramos numerados" (normalmente no topo), vi os dois maiores infratores a seguir :

Um de algo chamado pam_startque parece abrir imagens 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 que às vezes é seguido por outro infrator 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]

Então, basicamente, existem dois criminosos. Um é pam(algum tipo de sistema de autenticação) e o outro é o asl"detecte seu último login". Então, aparentemente, apenas excluir seus /private/var/log/asl/*.aslarquivos não é suficiente. O carregamento do pam é muito mais caro na minha máquina, de qualquer maneira [SSD]. Sinta-se livre para executar o script acima e veja se o seu sistema é o mesmo. Curiosamente, o código-fonte para essas chamadas de método também parece estar disponível online, por exemplo, openpam_dynamic

Se eu seguir a resposta de Darren e substituir minhas preferências de "shell aberto por" por algo diferente de / bin / bash, vejo as seguintes linhas usadas para iniciar novas guias de terminal:

 $ ps -ef | grep login
  ... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash

Portanto, se agora eu usar o mesmo sampletruque no novo comando de login

login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie

um stacktrace muito menor é gerado, sendo o maior infrator:

+         8 pam_end  (in libpam.2.dylib) + 190  [0x7fff97294ebb]
+             !           6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*)  (in dyld) + 143  [0x7fff6e0f634f]

Eu acho que isso ocorre porque o parâmetro de login "-q" está sendo usado agora. Aparentemente, esse parâmetro ignora o carregamento dos módulos pam e a consulta do último horário de login (ambos os infratores). De acordo com a documentação do logincomando, tocar no ~/.hushloginarquivo deve fazer a mesma coisa, mas aparentemente isso não funciona mais [pelo menos para mim com 10.10].

Portanto, em resumo, remover /private/var/log/asl/*.asl não é suficiente (no meu experimento, ele representou apenas 1/3 da desaceleração real, embora se você tivesse mais arquivos ali, ele poderia ser responsável para uma porcentagem maior, tenho certeza).

De qualquer forma, usando scripts semelhantes, você será capaz de dizer o que está causando um problema na sua máquina local e verificar se a correção acima se aplica a você. Sinta-se livre para comentar aqui.

UPDATE: parece que coresymbolication_load_imageainda pode demorar muito tempo, mesmo quando login -pfqlé invocado (presumivelmente, algum módulo de autenticação pam ou outro está tendo que "discar" para um servidor de login central ou algo estranho, portanto, é necessário aguardar uma resposta de um terceiro ) Portanto, a única solução real que encontrei é usar o iTerm2 e alterar as preferências -> profiles -> general -> Command em /bin/bashvez disso.


1
Além da pesquisa ASL, os atrasos no login são causados ​​com maior frequência por estar em uma rede com um servidor de diretório que responde lentamente quando solicitadas suas informações de usuário. Se você não estiver em uma rede com serviços de diretório ativados, não sei o que mais levaria um tempo significativo, além do congestionamento geral do sistema (uso da CPU, pressão de memória, congestionamento de E / S).
Chris Página

@ ChrisPage Sim, provavelmente alguns serviços de diretório de rede de uma maneira ou de outra, boa dica.
Rogerdpack #

3

É tudo uma questão de investigar a causa. Você pode ver o que está sendo feito enquanto o processo é iniciado, inserindo o bash -xque imprimirá o processo de inicialização do shell.

Pessoalmente, só percebo o atraso entre a ativação e a desativação do aplicativo e na primeira guia criada após um período de atividade. Sempre me faz pensar que se trata de movimentar páginas de memória.


2

Reduza seu histórico para algo entre 4 e 10 mil linhas e talvez tente sair e descartar todas as janelas salvas. Eu já vi os dois fazerem diferença em máquinas mais lentas - especialmente aquelas sem SSD para armazenamento.


2

No meu caso, depois de tentar o acima na minha máquina de trabalho sem sucesso, descobri que o culpado era o Active Directory. A correção foi entrar no Directory Utility e editar as configurações do serviço AD (clique duas vezes em "Active Directory") para ativar "Criar conta móvel no login":

captura de tela do aplicativo Directory Utility com as configurações do Active Directory abertas

Aparentemente, isso faz com que as credenciais do AD sejam armazenadas em cache localmente, para que o sistema não precise mais sair para o servidor toda vez que tentar validar sua senha.

Você pode acessar o Directory Utility with Spotlight ou através da seção "Opções de login" das Preferências do sistema / Usuários e grupos (selecione o botão "Editar ..." ao lado de "Servidor de contas de rede"):

Painel Usuários e grupos mostrando "Opções de login" e "Editar ..."


0

Apenas corra:

sudo creatbyproc.d
sudo newproc.d

em terminais separados e abra o novo open para ver o que está sendo executado durante esse período.

Se nada for óbvio, tente o seguinte:

sudo dtruss -an Terminal

Isso imprimirá todos os detalhes que estão acontecendo no tempo de carregamento da guia.


0

Abra /etc/profilee adicione a linha PATH=""para que fique assim:

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

0

O problema para mim foi que o servidor de domínio do diretório ativo era inválido.

Alterando-o e reiniciando o Mac, ele foi corrigido.

insira a descrição da imagem aqui

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.