¿Cómo acelero el nuevo tiempo de carga de la pestaña Terminal?

84

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

    
pregunta Fernando 25.02.2012 - 20:01

10 respuestas

83

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:

  1. Crea un enlace simbólico a tu shell preferido. Por ejemplo: sudo ln -s /bin/bash /usr/local/bin/bash
  2. Abre las Preferencias de la Terminal y selecciona 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: 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:

  • Abre una nueva ventana de Terminal.
  • "Último inicio de sesión:" no se debería mostrar no en la parte superior
  • Abra el inspector (Comando + I) y seleccione la pestaña Información.
  • El comando debe leer 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 .

    
respondido por el Darren 18.11.2012 - 12:44
14

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

    
respondido por el butcheriftexas 11.07.2015 - 13:36
14

.hushlogin

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 .

Silenciar el proceso de inicio de sesión

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.

    
respondido por el Graham Miln 19.06.2012 - 17:12
5

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.

    
respondido por el rogerdpack 06.02.2015 - 23:57
2

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.

    
respondido por el ismail 26.02.2012 - 01:48
2

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.

    
respondido por el bmike 08.04.2012 - 06:23
1

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"):

Usuarios&amperio;Paneldegruposquemuestra"Opciones de inicio de sesión" y "Editar ..."

    
respondido por el David Moles 27.08.2015 - 00:33
0

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.

    
respondido por el kenorb 26.03.2015 - 13:57
0

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
    
respondido por el davidcondrey 23.06.2015 - 03:07
0

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

    
respondido por el user2707671 30.01.2017 - 11:37

Lea otras preguntas en las etiquetas