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

Respuesta Corta:

El problema está causado por un (potencialmente) caro ASL registro del sistema de búsqueda. Para ver esto en acción, ejecutar sudo opensnoop | grep login en una ventana de Terminal, a continuación, abra una nueva ventana de Terminal.

Para resolver el problema, configure Terminal para lanzar un no-estándar de la shell:

1. Crear un enlace simbólico a su shell preferido. E. g.: sudo ln -s /bin/bash /usr/local/bin/bash
2. Abra el Terminal Preferencias y seleccione la pestaña "General".
3. Seleccione "Conchas se abran con: Comando" y entrar en el enlace creado en el paso 1. E. g. "/usr/local/bin/bash".

Nota 1: también puede necesitar 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 OS X 10.11 (El Capitan) Desarraigado modo.

Para verificar la corrección:

• Abrir una nueva ventana de Terminal.
• "El último inicio de Sesión:" si no se muestra en la parte superior
• Abra el inspector (Comando + I) y seleccione la pestaña de 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 -q parámetro, entonces usted no ha solucionado el problema.

También puede utilizar sudo opensnoop | grep login para comprobar que /var/log/asl no se accede a la hora de abrir una nueva ventana de Terminal.

Detalles:

Hay un número de errores en el juego aquí.

La causa real de la lentitud es /usr/bin/login, que, por defecto, se mostrará la fecha de tu última conexión. Para obtener este último inicio de sesión de la fecha, la busca en la ASL (Manzana Registro del Sistema) de la base de datos en /var/log/asl/. Estos archivos de registro puede ser muy muy fragmentado, y esta es la fragmentación de archivos que hace que el retraso en la apertura de una nueva ventana o pestaña. (Error 1)

La única forma de suprimir la ASL de búsqueda para el último inicio de sesión va a pasar a la -q parámetro /usr/bin/login. El .hushlogin archivo también suprimir la "Última conexión" de pantalla, pero no suprime la cara de la ASL de búsqueda. (Error 2)

El Terminal utiliza siempre /usr/bin/login el lanzamiento de cada nueva ventana/shell. No hay ninguna opción para lanzar un shell directamente ni existe una forma de controlar directamente los parámetros pasados a /usr/bin/login (Error 3).

Como resulta que el Terminal pasará a la -q parámetro /usr/bin/login cuando está configurado para utilizar un no-estándar de la shell. (Error 4)

El -q parámetro es lo que necesitamos para evitar el problema, por lo tanto el enlace a /usr/local/bin/bash.

Lo que yo necesitaba era cambiar de shell de inicio de sesión para comando /bin/bash -il en las preferencias=>perfiles=>General=>Comando configuración de iTerm2.

Yo necesitaba la opción -l bash actuar como si hubiera sido invocado como un shell de inicio de sesión añadido con el fin de establecer las variables de entorno de ~/.bash_profile

Crear un archivo vacío en su hogar carpeta llamada .hushlogin; esto disminuirá significativamente el tiempo que toma para un Terminal.aplicación de la ficha a aparecer.

Al crear una nueva pestaña de Terminal, usted va a través del proceso de inicio de sesión. El proceso consiste en la obtención de información diversa acerca de su anterior sesión de inicio de sesión, mensaje de la jornada, y la visualización de los mensajes del sistema. Este puede ser el origen de retrasos significativos. Intentar acallar estos mensajes para ver si el retraso desaparece.

Usted puede crear la .hushlogin archivo en la Terminal.aplicación mediante el siguiente comando:

touch ~/.hushlogin

El archivo se llevará a efecto inmediatamente.

Usted puede aprender más acerca de la .hushlogin de archivos y el proceso de inicio de sesión en general en el inicio de sesión manual.

OK tengo una conclusión similar a Darren, aunque ligeramente diferentes perfiles de mecanismo (NB lento inicio de sesión puede ocurrir en Yosemite).

He aquí una manera de decirle lo que en realidad se ejecuta cuando se inicia una nueva ventana de inicio de sesión, utilizando el OS X de muestra del analizador de comandos.

Averiguar lo que un comando de inicio de sesión normal executs

$ ps -ef | grep login

Te seee algo como login -pfl username /bin/bash -c exec -la bash /bin/bash

Crear un script de nombre de archivo profile_login.sh con el siguiente contenido mediante la adición de un

-c ""

al final de la descubrió comando para solicitar que bash regresar 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

Hacerlo ejecutable

$ chmod u+x profile_login.sh

y ejecutarlo usando sudo (sample comando requiere)

$ sudo ./profile_login.sh

OK, así que adelante y ejecutar. Por ejemplo, mediante la ejecución de la purge comando en primer lugar. En mi caja, tengo una gran salida gráfica. En busca de la "más grande numeradas ramas" (normalmente en la parte superior) vi las dos siguientes más grande de los delincuentes:

Uno de algo que se llama pam_start que aparece a la apertura de pam auth lib imágenes

+   ! 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 es que, a veces, 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]

Así que, básicamente, existen dos delincuentes. Una es pam (algún tipo de sistema de autenticación) y el otro es el asl "detectar su último inicio de sesión". Así que al parecer acaba de eliminar su /private/var/log/asl/*.asl archivos no es suficiente. El pam de carga es mucho más caro que en mi máquina, de todos modos [SSD]. Siéntase libre de ejecutar el script de arriba y ver si su sistema es el mismo. Curiosamente, el código fuente de estas llamadas al método parece estar también disponible en línea, por ejemplo openpam_dynamic

Si sigo Darren respuesta, y sustituir a mi "conchas abrir con" preferencia a algo distinto de /bin/bash, me, a continuación, consulte las siguientes líneas se utiliza para iniciar la nueva terminal de pestañas:

 $ ps -ef | grep login
  ... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash

Así que si yo 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

mucho menor stacktrace se genera, el mayor delincuente de ser:

+         8 pam_end  (in libpam.2.dylib) + 190  [0x7fff97294ebb]
+             !           6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*)  (in dyld) + 143  [0x7fff6e0f634f]

Creo que esto es debido a que el inicio de sesión "-q" parámetro se usa ahora. Al parecer, este parámetro se omite tanto la carga de los módulos pam y busca hasta el último momento de inicio de sesión (tanto los delincuentes). De acuerdo a la documentación de la login comando, tocar la ~/.hushlogin archivo debería hacer lo mismo, pero al parecer esto ya no funciona (al menos para mí, con 10.10].

Así que, en resumen, la eliminación /private/var/log/asl/*.asl no es suficiente (en mi experimento, sólo representaron a más de 1/3 de la actual desaceleración, aunque si tenía costumbres de archivos no se podría dar cuenta de un porcentaje mayor, estoy seguro).

De todos modos, utilizando similares secuencias de comandos, usted debe ser capaz de decir cuál es la causa de su máquina local a estancar, y ver si la revisión anterior se aplica a usted. Siéntase libre de comentar aquí.

ACTUALIZACIÓN: parece que coresymbolication_load_image aún puede tomar un montón de tiempo, incluso cuando login -pfql se invoca (es de suponer que algunos de autenticación pam, módulo u otro es la necesidad de "marcar" a un centro servidor de inicio de sesión o de algún extraño, así que tiene que esperar por una respuesta de un 3rd party). Así que la única verdadera solución que he encontrado es usar iTerm2, y cambiar las preferencias -> perfiles -> general -> Comando para /bin/bash lugar.

Es todo acerca de la investigación de la causa. Usted puede ver lo que se está haciendo mientras el proceso se inicia con la inputing bash -x que se imprimirá el proceso de arranque de la shell.

Personalmente, yo sólo aviso de que el retardo entre la activación y la desactivación de la aplicación y en la primera pestaña creado después de un periodo de actividad. Siempre me hace pensar que se trata de páginas de memoria se mueven.