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


93

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


2
Tal vez hay algo más mal con su sistema? No debería ser tan lento. A veces me lleva uno o dos segundos, pero generalmente es solo una fracción de segundo. Y tengo un poco en .bash_profile(también verifique ~/.profilepor 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.
Abhi Beckert

¿Está utilizando una cuenta de red o un directorio de inicio de red? ¿El terminal responde a la entrada del usuario mientras crea el terminal? ¿Muestra el cursor ocupado que gira?
Chris Page

1
Para saber dónde está pasando el tiempo Terminal, abra el Monitor de actividad, seleccione Terminal y haga clic en el botón de la barra de herramientas Proceso de muestra, luego vaya inmediatamente a Terminal y cree una nueva ventana / pestaña. La muestra puede proporcionar una pista de a dónde va el tiempo. Además, mire la lista de procesos en el Monitor de actividad: si aparece "inicio de sesión" o "bash" (o cualquier shell que esté usando) en la lista durante el retraso, eso significa que es probable que el retraso ocurra en uno de esos dos programas y no Terminal.
Chris Page

¿Has comprobado tu variable PATH? Noté que la mía era absurdamente larga con muchas repeticiones debido a algunos confusos .bashrc. ¡Eliminé las repeticiones y todo se aceleró!
190290000 Rublo Man

Respuestas:


93

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.


66
¿Sabe por qué se agrega -q si el comando es un enlace simbólico a / bin / bash pero no si es / bin / bash?
Lri

3
@LauriRanta Parece ser un error en la Terminal 10.7 y 10.8. Cuando el comando de inicio está configurado, /bin/bashse comporta como si se hubiera seleccionado el Shell de inicio de sesión predeterminado. Cualquier comando que /bin/bashno sea el correcto funcionará, por lo que usar / usr / bin / bash es solo una solución alternativa. Este error no está presente en Snow Leopard.
Darren

55
@ Darren, ¿has informado de este posible error a Apple? De lo contrario, podría hacerlo a través de: bugreport.apple.com
Graham Miln

3
Desafortunadamente, esto da como resultado una advertencia sobre la ejecución de bash cada vez que cierra la terminal en Yosemite. Así que no es una buena solución :(
Claus Jørgensen

2
@ ClausJørgensen No he experimentado ese problema. Es posible que desee comprobar la configuración de "Shell" en la pestaña Perfiles.
Darren

20

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


Lo que detiene la búsqueda de inicio de sesión de ASL según la pregunta aceptada
user151019

44
De todas las soluciones, esta funcionó para mí. +50!
Bhavin Doshi

1
¡Gran información en este hilo! Esta es la solución que utilicé porque no requería crear enlaces simbólicos ni nada. Mis nuevos tiempos de inicio de shell han pasado de ~ 5-10 segundos a instantáneo con esta solución.
DustinB

16

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


66
.hushlogin en realidad no resuelve el problema. Esto se puede confirmar mediante el uso opensnoop. Vea mi respuesta a continuación.
Darren

1
@Darrren: el inicio de sesión de man me dice: -q Esto fuerza inicios de sesión silenciosos, como si hubiera un .hushlogin. La opción q es lo que dice que previene el problema, pero simplemente hace lo mismo que con hushlogin.
Christian

8

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.


1
Además de la búsqueda de ASL, los retrasos en el inicio de sesión son causados ​​con mayor frecuencia por estar en una red con un servidor de directorio que responde lentamente cuando se le solicita su información de usuario. Si no está en una red con servicios de directorio habilitados, entonces no sé qué más tomaría un tiempo significativo, aparte de la congestión general del sistema (uso de CPU, presión de memoria, congestión de E / S).
Chris Page

@ChrisPage Sí, probablemente, algunos servicios de directorio de red, una cosa u otra, un buen consejo.
rogerdpack

3

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.


2

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.


2

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

captura de pantalla de la aplicación Directory Utility con la configuración de Active Directory abierta

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

Panel de usuarios y grupos que muestra "Opciones de inicio de sesión" y "Editar ..."


0

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.


0

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

0

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

ingrese la descripción de la imagen aquí

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.