¿Cómo puedo acelerar el inicio del terminal en Lion?
No me refiero al inicio de la aplicación de Terminal, sino a las ventanas de terminal de inicio, como cuando abro una nueva pestaña.
No tengo nada en mi archivo .bash_profile y ejecuto rm -rf /private/var/log/asl/*.asl cada 4 horas (lo que borra los archivos que normalmente hacen que el terminal sea lento).
Actualmente, cuando abro una nueva pestaña, toma de 3 a 4 segundos hasta que pueda ejecutar algo.
Respuesta corta:
El problema se debe a una búsqueda de registro del sistema ASL (potencialmente) costosa. Para ver esto en acción, ejecute sudo fs_usage | grep 'asl.*login' en una ventana de Terminal, luego abra una nueva ventana de Terminal.
Para resolver el problema, configure Terminal para iniciar un shell no estándar:
sudo ln -s /bin/bash /usr/local/bin/bash
Nota 1: Es posible que también deba agregar bash y -bash a la lista de procesos en "Preferencias de Terminal > Perfiles > Shell > Preguntar antes de cerrar".
Nota 2: /usr/local/bin se puede escribir en el modo Rootless de OS X 10.11 (El Capitán).
Para verificar la solución:
login -pfq username /usr/bin/bash o login -pfql username ...
Importante: si el comando de inicio de sesión no incluye el parámetro -q , entonces no ha solucionado el problema.
También puedes usar sudo fs_usage | grep 'asl.*login' para verificar que no se acceda a /var/log/asl al abrir una nueva ventana de Terminal.
Detalles :
Hay varios errores en juego aquí.
La causa real de la lentitud es /usr/bin/login , que de forma predeterminada mostrará la fecha de su último inicio de sesión. Para obtener esta última fecha de inicio de sesión, busca en la base de datos ASL (registro del sistema Apple) en /var/log/asl/ . Estos archivos de registro pueden estar muy fragmentados y es esta fragmentación del archivo la que causa el retraso al abrir una nueva ventana o pestaña. (Error 1)
La única forma de suprimir la búsqueda ASL para el último inicio de sesión es pasar el parámetro -q a /usr/bin/login . El archivo .hushlogin también suprimirá la pantalla de "Último inicio de sesión", pero no suprime la búsqueda costosa de ASL. (Error 2)
El terminal siempre usa /usr/bin/login para iniciar cada nueva ventana / shell. No hay una opción para iniciar un shell directamente ni hay una manera de controlar directamente los parámetros pasados a /usr/bin/login (Error 3).
Resulta que, la Terminal pasará el parámetro -q a /usr/bin/login cuando esté configurado para usar un shell no estándar . (Error 4)
El parámetro -q es lo que necesitamos para evitar el problema, de ahí el enlace simbólico a /usr/local/bin/bash .
Lo que necesitaba era cambiar de shell de inicio de sesión al comando /bin/bash -il
en las Preferencias > de iTerm Perfiles > General > Comando .
Necesitaba la opción -l ( Make bash act como si se hubiera invocado como shell de inicio de sesión ) agregada para establecer las variables de entorno de ~/.bash_profile
Crea un archivo vacío en tu carpeta de inicio llamado .hushlogin ; esto disminuirá significativamente el tiempo que tarda en aparecer una pestaña de Terminal.app.
Puede crear el archivo .hushlogin en Terminal.app usando el siguiente comando:
touch ~/.hushlogin
El archivo entrará en vigor de inmediato.
Puede obtener más información sobre el archivo .hushlogin y el proceso de inicio de sesión en general en login manual .
Cuando crea una nueva pestaña de Terminal, está pasando por el proceso de inicio de sesión. El proceso implica obtener información diversa sobre su sesión de inicio de sesión anterior, el mensaje del día y mostrar los mensajes del sistema. Esto puede ser la fuente de retrasos significativos. Intente silenciar estos mensajes para ver si el retraso desaparece.
Bien, tengo una conclusión similar a la de Darren, aunque un mecanismo de creación de perfiles ligeramente diferente (NB puede iniciar sesión lenta en Yosemite).
Esta es una manera de decirle a qué se está ejecutando cuando inicia una nueva ventana de inicio de sesión, utilizando el OS X sample comando del generador de perfiles.
Averigüe 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 ""
hasta el final del comando descubierto para solicitar que bash vuelva inmediatamente, 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útelo usando sudo (el comando sample lo requiere)
$ sudo ./profile_login.sh
OK así que adelante y ejecútalo. Por ejemplo, ejecutando el comando purge primero. En mi caja, tengo un gran gráfico de salida. Buscando las "ramas numeradas más grandes" (generalmente en la parte superior) vi los siguientes delincuentes más grandes :
Uno de algo llamado pam_start que parece abrir imágenes pam auth lib 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 es seguido a veces 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 "detecte su último inicio de sesión". Entonces, aparentemente, simplemente eliminar los archivos /private/var/log/asl/*.asl no es suficiente. La carga de pam es mucho más cara 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 de método también parece estar disponible en línea, por ejemplo, openpam_dynamic
Si sigo la respuesta de Darren y sustituyo mi preferencia de "shells open with" a algo que no sea / bin / bash, veo las siguientes líneas utilizadas para iniciar nuevas pestañas de terminales:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
Entonces, si ahora uso el mismo truco sample 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, el mayor infractor es:
+ 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". Al parecer, este parámetro omite la carga de los módulos pam y en busca del último tiempo de inicio de sesión (ambos infractores). De acuerdo con los documentos del comando login , tocar el archivo ~/.hushlogin debería hacer lo mismo, pero al parecer 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 tenía más archivos allí podría dar cuenta de 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 toneladas de tiempo, incluso cuando se invoca login -pfql (probablemente un módulo de autenticación pam u otro es tener que "marcar" a un servidor central de inicio de sesión o algo extraño, así que esperar una respuesta de un tercero). Así que la única solución real que he encontrado es usar iTerm2 y cambiar las preferencias - > perfiles - > general - > Comando a /bin/bash en su lugar.
Se trata de investigar la causa. Puede ver lo que se está haciendo mientras se inicia el proceso ingresando bash -x que imprimirá el proceso de inicio de la shell.
Personalmente, solo noté el retraso entre la activación y la desactivación de la aplicación y en la primera pestaña creada después de un período de actividad. Siempre me hace pensar que se trata de páginas de memoria que se mueven.
Reduzca su historial a algo entre 4 y 10 mil líneas y quizás intente salir y descartar todas las ventanas guardadas. He visto que ambos marcan la diferencia en máquinas más lentas, especialmente las que no tienen SSD para almacenamiento.
En mi caso, después de intentar lo anterior en mi máquina de trabajo sin éxito, descubrí que el culpable era Directorio Activo. La solución fue ir a Directory Utility y editar la configuración del servicio AD (haga doble clic en "Active Directory") para habilitar "Crear cuenta móvil al iniciar sesión":
Aparentemente,estohacequelascredencialesdeADsealmacenenencachélocalmente,porloqueelsistemayanotienequeiralservidorcadavezqueintentavalidarsucontraseña.
PuedeaccederaDirectoryUtilityconSpotlightoatravésdelasección"Opciones de inicio de sesión" de Preferencias del sistema / Usuarios & Grupos (seleccione el botón "Editar ..." junto a "Servidor de cuentas de red"):
Solo ejecuta:
sudo creatbyproc.d
sudo newproc.d
en terminales separados y abra el nuevo abierto para ver qué se está ejecutando durante ese tiempo.
Si no hay nada obvio, intente lo siguiente:
sudo dtruss -an Terminal
Esto imprimirá todos los detalles que están ocurriendo en el tiempo de carga de la pestaña.
Abre /etc/profile y agrega la línea PATH="" para que se vea así:
if [ -x /usr/libexec/path_helper ]; then
PATH=""
eval '/usr/libexec/path_helper -s'
fi
El problema para mí fue que el servidor de dominio de directorio activo no era válido.
Cambiarlo y luego reiniciar el mac lo solucionó.
Lea otras preguntas en las etiquetas terminal macos command-line