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.
.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.