OK, tengo una conclusión similar a Darren, aunque un mecanismo de creación de perfiles ligeramente diferente (NB, el inicio de sesión lento todavía puede ocurrir en Yosemite).
Aquí hay una manera de saber qué se está ejecutando realmente cuando inicia una nueva ventana de inicio de sesión, utilizando el comando OS X sample profiler.
Descubra qué comando ejecuta un inicio de sesión normal
$ ps -ef | grep login
Verás algo como login -pfl username /bin/bash -c exec -la bash /bin/bash
Cree un nombre de archivo de script profile_login.sh
con el siguiente contenido agregando un
-c ""
al final del comando descubierto para solicitar que bash regrese de inmediato, con contenidos como este:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
Hazlo ejecutable
$ chmod u+x profile_login.sh
y ejecútalo usando sudo (el sample
comando lo requiere)
$ sudo ./profile_login.sh
OK, entonces adelante y ejecútalo. Por ejemplo, ejecutando el purge
comando primero. En mi caja, obtuve un gran gráfico de salida. Buscando las "ramas numeradas más grandes" (típicamente en la parte superior) vi a los siguientes dos delincuentes más grandes :
Uno de algo llamado pam_start
que parece abrir imágenes 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]
y eso a veces es seguido por otro delincuente 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]
Básicamente, hay dos delincuentes. Uno es pam
(algún tipo de sistema de autenticación) y el otro es asl
"detectar su último inicio de sesión". Aparentemente, simplemente eliminar sus /private/var/log/asl/*.asl
archivos no es suficiente. La carga de pam es mucho más costosa en mi máquina, de todos modos [SSD]. Siéntase libre de ejecutar el script anterior y ver si su sistema es el mismo. Curiosamente, el código fuente para estas llamadas a métodos también parece estar disponible en línea, por ejemplo openpam_dynamic
Si sigo la respuesta de Darren y reemplazo mis preferencias de "shells open with" por algo que no sea / bin / bash, entonces veo las siguientes líneas utilizadas para iniciar nuevas pestañas de terminal:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Entonces, si ahora uso el mismo sample
truco en el nuevo comando de inicio de sesión
login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie
se genera un seguimiento de pila mucho más pequeño, siendo el mayor infractor:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
Creo que esto se debe a que ahora se está utilizando el parámetro de inicio de sesión "-q". Aparentemente, este parámetro omite cargar los módulos de pam y buscar el último tiempo de inicio de sesión (ambos delincuentes). Según los documentos del login
comando, tocar el ~/.hushlogin
archivo debería hacer lo mismo, pero aparentemente esto ya no funciona [al menos para mí con 10.10].
Entonces, en resumen, eliminar /private/var/log/asl/*.asl no es suficiente (en mi experimento, solo representó como máximo 1/3 de la desaceleración real, aunque si tuviera más archivos allí podría tener en cuenta para un mayor porcentaje estoy seguro).
De todos modos, utilizando scripts similares, debería poder saber qué está causando que su máquina local se atasque y ver si la solución anterior se aplica a usted. Siéntete libre de comentar aquí.
ACTUALIZACIÓN: parece que coresymbolication_load_image
todavía puede llevar mucho tiempo, incluso cuando login -pfql
se invoca (presumiblemente, algún módulo de autenticación de pam u otro está teniendo que "marcar" a un servidor de inicio de sesión central o algo extraño, por lo que tiene que esperar la respuesta de un tercero ) Entonces, la única solución real que he encontrado es usar iTerm2 y cambiar las preferencias -> perfiles -> general -> Comando a /bin/bash
.
.bash_profile
(también verifique~/.profile
por cierto). Además: tenga en cuenta que puede comenzar a escribir mientras se carga bash, y generalmente lo que escribe se copiará en el símbolo del sistema una vez que esté listo.