¿Como puedo acelerar el inicio del terminal en Lion?

No me refiero al inicio de la aplicación Terminal, sino a las ventanas del 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/*.aslcada 4 horas (lo que borra esos archivos que generalmente hacen que la terminal sea lenta).

Actualmente, cuando abro una nueva pestaña, me toma 3-4 segundos hasta que pueda ejecutar algo.

Respuesta corta:

El problema es causado por una (potencialmente) costosa búsqueda de registro del sistema ASL. 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:

1. Cree un enlace simbólico a su shell preferido. P.ej:sudo ln -s /bin/bash /usr/local/bin/bash
2. Abra Preferencias de terminal y seleccione la pestaña "General".
3. Seleccione "Shells open with: Command" e ingrese el enlace simbólico que creó en el paso 1. Por ejemplo, "/ usr / local / bin / bash".

Nota 1: También es posible que deba agregar bashy agregar -basha la lista de procesos en "Preferencias de terminal> Perfiles> Shell> Preguntar antes de cerrar".

Nota 2: /usr/local/binse puede escribir en modo OS X 10.11 (El Capitan) Rootless.

Para verificar la solución:

• Abre una nueva ventana de Terminal.
• "Último inicio de sesión:" no debe mostrarse en la parte superior
• Abra el inspector (Comando + I) y seleccione la pestaña Información.
• El comando debería leer login -pfq username /usr/bin/bashologin -pfql username ...

Importante: si el comando de inicio de sesión no incluye el -qparámetro, entonces no ha solucionado el problema.

También puede usar sudo fs_usage | grep 'asl.*login'para verificar que /var/log/aslno se accede al abrir una nueva ventana de Terminal.

Detalles:

Hay una serie de errores en juego aquí.

La causa real de la lentitud es /usr/bin/loginque, 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 de 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 de ASL para el último inicio de sesión es pasar el -qparámetro a /usr/bin/login. El .hushloginarchivo también suprimirá la pantalla "Último inicio de sesión", pero no suprime la costosa búsqueda de ASL. (Error 2)

La terminal siempre usa /usr/bin/loginpara lanzar cada nueva ventana / shell. No hay una opción para iniciar un shell directamente ni hay una forma de controlar directamente los parámetros pasados ​​a /usr/bin/login(Bug 3).

Como resultado, Terminal pasará el -qparámetro /usr/bin/logincuando esté configurado para usar un shell no estándar . (Error 4)

El -qparámetro 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 a comando /bin/bash -il en las Preferencias de iTerm > Perfiles> General> Comando .

Necesitaba agregar la opción -l( Hacer que bash actúe como si se hubiera invocado como un shell de inicio de sesión ) para establecer variables ambientales desde~/.bash_profile

.hushlogin

Cree un archivo vacío en su carpeta de inicio llamado .hushlogin; esto disminuirá significativamente el tiempo que tarda una pestaña Terminal.app en aparecer.

Puede crear el .hushloginarchivo en Terminal.app usando el siguiente comando:

touch ~/.hushlogin

El archivo entrará en vigencia de inmediato.

Puede obtener más información sobre el .hushloginarchivo y el proceso de inicio de sesión en general en el manual de inicio de sesión .

Silenciar el proceso de inicio de sesión

Cuando crea una nueva pestaña 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 mensajes del sistema. Esto puede ser la fuente de retrasos significativos. Intenta silenciar estos mensajes para ver si la demora desaparece.

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.shcon 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 samplecomando lo requiere)

$ sudo ./profile_login.sh

OK, entonces adelante y ejecútalo. Por ejemplo, ejecutando el purgecomando 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_startque 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/*.aslarchivos 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 sampletruco 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 logincomando, tocar el ~/.hushloginarchivo 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_imagetodavía puede llevar mucho tiempo, incluso cuando login -pfqlse 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.

Se trata de investigar la causa. Puede ver lo que se está haciendo mientras el proceso comienza ingresando bash -xlo que imprimirá el proceso de inicio del shell.

Personalmente, solo noto 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 mover páginas de memoria.

Reduzca su historial a 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 aquellas sin SSD para almacenamiento.

En mi caso, después de probar lo anterior en mi máquina de trabajo sin éxito, descubrí que el culpable era Active Directory. La solución fue ir a la Utilidad de directorio y editar la configuración del servicio de AD (hacer doble clic en "Active Directory") para habilitar "Crear cuenta móvil al iniciar sesión":

Aparentemente, esto hace que las credenciales de AD se almacenen en caché localmente, por lo que el sistema ya no tiene que salir al servidor cada vez que intenta validar su contraseña.

Puede acceder a la Utilidad de directorio con Spotlight o mediante la sección "Opciones de inicio de sesión" de Preferencias del sistema / Usuarios y grupos (seleccione el botón "Editar ..." junto a "Servidor de cuentas de red"):

Solo corre:

sudo creatbyproc.d
sudo newproc.d

en terminales separadas 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 sus detalles que están sucediendo en el tiempo de carga de la pestaña.

Abra /etc/profiley agregue 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 del directorio activo no era válido.

Cambiarlo y luego reiniciar el mac lo arregló.