Tengo un problema extraño en mi nuevo MacBook Pro (finales de 2016, barra táctil).

Funciona bien y luego, después de usarlo por un tiempo, abrir nuevas ventanas de Terminal no funciona porque se loginbloquea. El reinicio soluciona el problema.

Esto parece ser un problema que otras personas han tenido, así que probé todas sus soluciones (desde 1 y [2] ):

1. Quitando ~/Library/Preferences/com.apple.Terminal.plist
2. Configuración de mi shell por defecto a otra línea de comandos (a partir /bin/zshde /bin/sho /bin/bash)
3. Eliminar o limpiar mi .profile, .zprofile... Esto no funciona y puedo validar que el problema se produce incluso antes de que se invoque el shell, porque si yo echo HEYcomo la primera línea de mi .zshenvni siquiera se alcanza. Debe estar logincausando los problemas. La edición /etc/profilepara agregar un eco en la parte superior tampoco muestra nada
4. Cambiar la Run command:configuración en mi configuración de Terminal a algo así echo footampoco funciona (dejar Run inside shellmarcado o desmarcado no cambia nada).

Otras notas:

• Al igual que [2] , ssh-add -Kno persiste las teclas entre reinicios, algo con lo que nunca tuve problemas antes.
• La consola no muestra errores o advertencias sospechosas.
• Abrir una nueva Terminalventana parece crear un archivo tty ( /dev/ttys<number>).
• Cuando esto ocurre, no importa si uso Terminal.app o iTerm.app
• Tengo una instalación bastante limpia (acabo de recibir mi computadora portátil, no restauré ninguna copia de seguridad, solo instalé algunas aplicaciones con brew instally brew cask install).

Esto es realmente difícil de depurar porque no puedo reproducirlo y, a menudo, no puedo abrir un nuevo terminal para tratar de averiguar qué está pasando.

¿Alguien tiene algún consejo?

Actualizar:

Usando iTerm, pude obtener un shell configurando el comando de inicio en /bin/bash. En este shell, sin embargo, sudono funciona. Se cuelga (sin mostrar el símbolo) y ctrl-Cy ctrl-Dno hacer el trabajo cuando se cuelga.

El uso de algunos otros programas tampoco funciona en este shell: nodeo /usr/local/bin/nodeambos se bloquean. Por lo que puedo decir, son los programas los que están incluidos /usr/local/bin.

Actualización 2:

brew list --full-name resultados en estos paquetes:

autoconf
automake
blueutil
boost
cabal-install
cairo
cfssl
cmake
coreutils
doxygen
editorconfig
erlang
ffind
ffmpeg
flow
fontconfig
fontforge
freetype
gdbm
gettext
ghc
git
glib
go
gobject-introspection
graphicsmagick
harfbuzz
haskell-stack
highlight
icu4c
influxdb
jemalloc
jpeg
keybase
lame
libevent
libffi
libpng
libtermkey
libtiff
libtool
libuv
libvterm
libxml2
lua
mongodb
msgpack
nginx
node
openssl
openssl@1.1
pango
pcre
pixman
pkg-config
postgresql
protobuf
python
python3
rabbitmq
readline
reattach-to-user-namespace
redis
sqlite
the_silver_searcher
thefuck
tmux
unibilium
unixodbc
wxmac
x264
xvid
xz
yarn
z
zsh
josegonzalez/php/php54
neovim/neovim/neovim

Actualización 3:

Estos puntos están en correspondencia con la respuesta de @ Monomeeth:

1. Cuando sucede, un loginelemento aparece en el monitor de actividad. (Forzar) Salir también cierra la ventana de Terminal que estaba colgando. Cerrar la ventana manualmente no hace que el loginproceso desaparezca en el Monitor de actividad.

2. El título del terminal es Terminal — login — term big — ttys001 — 89x18 — ⌘1, donde term bigestá el nombre de la configuración.

3. No se sudomuestra ningún proceso en el Monitor de actividad. Puedo crear un sudoproceso abriendo iTerm.app (que usa bash) y ejecutándome sudo echo okallí. No se puede salir, pero Force Quit funciona y lo mata:

   bash-3.2 $ sudo echo ok Muerto: 9

Actualización 4:

Cuando esto ocurre, se ejecuta logindesde un shell que aún está disponible hace el trabajo, mientras que el loginde los nuevos proyectiles parece colgar.

Actualización 5:

Recientemente obtuve una nueva computadora portátil (MacBook Pro 2017, sin Touch Bar) y el problema persiste.

También he cambiado de shells: ahora estoy usando fishuna configuración bastante vainilla. Creo que eso descarta la cáscara como el culpable.

El sistema operativo también se ha actualizado a 10.13.3 (17D47) High Sierra.

Intenté instalar lo menos posible en esta máquina:

brew list —-full-names

coreutils 8.29
dnsmasq 2.78
faac 1.29.9.2
fdk-aac 0.1.5
ffmpeg 3.4.1
fish 2.7.1
freetype 2.9
gdbm 1.14.1_1
gettext 0.19.8.1
git 2.16.1
highlight 3.42
htop 2.0.2_2
icu4c 60.2
imagemagick 7.0.7-22
jemalloc 5.0.1
jpeg 9b
lame 3.100
libav 12.2
libogg 1.3.3
libpng 1.6.34
libtermkey 0.20
libtiff 4.0.9_1
libtool 2.4.6_1
libuv 1.19.1
libvorbis 1.3.5_1
libvpx 1.7.0
libvterm 681
libyaml 0.1.7
lua 5.3.4_2
luajit 2.0.5
mongodb 3.6.2
msgpack 2.1.5
neovim 0.2.2
node 9.5.0
openssl 1.0.2n
opus 1.2.1
parallel 20180122
pcre 8.41
pcre2 10.30
postgresql 10.2
python 2.7.14_3
python3 3.6.4_2
readline 7.0.3_1
ripgrep 0.7.1
ruby 2.5.0
sqlite 3.22.0
the_silver_searcher 2.1.0
thefuck 3.25_1
unibilium 1.2.1
x264 r2795
xvid 1.3.5
xz 5.2.3
youtube-dl 2018.02.08

No estoy seguro de lo que puede ser ahora. Las únicas aplicaciones que se me ocurren son Divvyo Apptivateya que ambas parecen anticuadas. Esta es la intersección de lo que se instaló en la máquina antigua frente a la nueva:

coreutils
ffmpeg
freetype
gdbm
gettext
git
highlight
icu4c
jemalloc
jpeg
lame
libpng
libtermkey
libtiff
libtool
libuv
libvterm
lua
mongodb
msgpack
node
openssl
pcre
postgresql
python
python3
readline
sqlite
the_silver_searcher
thefuck
unibilium
x264
xvid
xz

Actualización 6:

Además, aquí hay una captura de pantalla:

Actualización 7:

Mi env normalmente se ve así:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.k60Nf5UBfq/Render
DISPLAY=/private/tmp/com.apple.launchd.6FMoWPSlJI/org.macosforge.xquartz:0
EDITOR=env VIRTUAL_ENV= nvim -u /Users/john-doe/.config/vim/vimrc -p
GNUTERM=X11
HOME=/Users/romeo
HOMEBREW_NO_EMOJI=1
HOMEBREW_PREFIX=/usr/local
LANG=en_GB.UTF-8
LESS=-RI
LESSHISTFILE=-
LOGNAME=romeo
LS_COLORS=di=00;31:ex=00;37:mi=00;41;30:tw=00;33
MANPATH=/usr/local/opt/coreutils/libexec/gnuman
PAGER=less
PATH=/Users/john-doe/.config/fisherman/re-search:/usr/local/opt/python/libexec/bin:/usr/local/opt/ruby/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin
PWD=/Users/romeo
SECURITYSESSIONID=186a8
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.fQn5sHMuZP/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=400
TERM_SESSION_ID=D2AF7A50-8B41-4793-9201-8304A02C9B29
TMPDIR=/var/folders/15/zcyyfw_x7638z7vfg5zd85z40000gn/T/
USER=romeo
XDG_CACHE_HOME=/Users/john-doe/.cache
XDG_CONFIG_HOME=/Users/john-doe/.config
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0

Como estoy seguro de que sabe, la solución de problemas es un proceso de eliminación y, a menudo, requiere un poco de paciencia. Me gustaría probar algunas cosas para tratar de llegar al fondo de esto para usted.

1. Confirme que se cuelga durante el inicio de sesión

Si el proceso en el que se cuelga es realmente durante el inicio de sesión , esto implica que el proceso todavía está esperando crear una sesión de inicio de sesión. Suponiendo que este sea el caso, entonces no habría intentado iniciar el shell todavía.

Para confirmar esto, la próxima vez que experimente este problema, inicie Activity Monitor para verificar si el shell se está ejecutando o si solo ve un proceso de inicio de sesión .

Una vez que haya tenido la oportunidad de hacer esto, informe de nuevo con lo que encontró.

NOTA: - Si tiene otros terminales abiertos, asegúrese de verificar el proceso correspondiente. Supongo que el proceso de suspensión es el que tiene el número más alto de ID de proceso (PID).

2. ¿Cuál es el título de la Terminal?

La próxima vez que tenga este problema, ¿puede tomar nota de cuál es el título de la ventana Terminal e informar?

3. Mata sudo

Usted afirma que reiniciar su MBP siempre resuelve este problema.

Sin embargo, la próxima vez que tenga este problema (tal vez después de hacer lo que describí en 1 arriba), me gustaría que intente matar a sudo desde el Monitor de actividad.

Una vez que hayas probado esto, cuéntanos qué sucede.

4. Intente mover sus archivos .bash *

Es posible (por varias razones) que tenga un archivo .bash_profile en su directorio de usuario y esto está causando problemas intermitentes. Esto es algo de lo que quizás ni siquiera se dé cuenta, pero puede usar Automator para ejecutar un script que encuentre y mueva cualquier archivo .bash.

Aquí hay un script de ejemplo para hacer esto:

cd ~

mkdir moved
for F in .bash*
do
    mv $F moved
done

Este script mueve todos los archivos que comienzan con .bash en su carpeta de inicio a una subcarpeta movida recién creada .

Después de ejecutar el script, verifique esta carpeta e infórmenos si de hecho tiene algún archivo.

NOTA: - Puede etiquetar la nueva subcarpeta como desee. Para hacerlo, simplemente cambie las dos ocurrencias de mover en el script a la etiqueta que desee usar.

[ACTUALIZAR]

Algunas cosas más para probar.

5. Intente borrar los archivos * .asl

Si aún no lo ha hecho, intente borrar los archivos * .asl. Para hacer esto use lo siguiente:

sudo rm -rf /private/var/log/asl/*.asl

NOTA: - Esto puede demorar un poco, ya que crea un nuevo shell. Cuando finalice, asegúrese de salir completamente de la Terminal para que los cambios surtan efecto.

6. Modo seguro

¿Notas alguna diferencia en el comportamiento cuando inicias tu MBP en modo seguro? Para iniciar en modo seguro:

1. Apaga completamente tu Mac
2. Reinicia tu Mac
3. Inmediatamente presione la Shifttecla y manténgala presionada
4. Suelte la Shifttecla cuando vea la ventana de inicio de sesión (NOTA: si tiene habilitado FileVault, es posible que deba iniciar sesión dos veces).
5. Una vez que se inicie su MBP, intente usar Terminal y vea si aún puede replicar el problema.
6. Cuando termine, puede salir del modo seguro reiniciando su MBP de manera normal

7. Directorio abierto

Esto probablemente no se aplique en su caso, ya que no lo menciona, pero si está conectado a una red de Open Directory, esto también podría estar causándole problemas. Por lo general, esto solo implicaría esperar entre 10 y 15 segundos, pero he visto informes de inicios de sesión en el terminal que tardan cinco o más minutos en completarse en esta situación.

Esto parece un ajuste perfecto para usted que excede los procesos máximos por usuario (o posiblemente procesos máximos).

En una instalación de stock de macOS, obtienes 709 por usuario ( ulimit -u) y 1064 procesos máximos ( sysctl -a | grep maxp)

Una manera fácil de aumentarlos es instalar Server.app desde App Store y luego reiniciar. También puede establecer el modo de rendimiento para límites más altos.

Dado que no describió su configuración (versión y compilación del sistema operativo), aquí hay algunos consejos: asegúrese de verificar si SIP restringe su capacidad de cambiar archivos si lee algunos de los artículos anteriores sobre cómo cambiar los límites sin recurrir a la instalación del servidor. aplicación:

• ¿Cómo aumento "ulimit -u" (procesos de usuario máximos)?
• http://blog.dekstroza.io/ulimit-shenanigans-on-osx-el-capitan/
• https://support.apple.com/en-us/HT3854
• https://support.apple.com/en-us/HT4022
• /server/15564/where-are-the-default-ulimits-specified-on-os-x-10-5

También he estado viendo esto durante varios meses. Extremadamente frustrante. Lo único que lo soluciona es reiniciar.

• Mediados de 2015 MBP (sin barra táctil)
• MacOS 10.12.6 beta

A veces, el inicio de sesión se bloquea después de interactuar con tmux.

He intentado sin éxito todos los enfoques recomendados.

No estoy seguro de si está relacionado, pero lsof -p LOGIN_PIDmuestra un archivo bastante masivo /private/var/db/dyld/dyld_shared_cache_x86_64hpara el proceso de inicio de sesión bloqueado.

8/29/2017 Actualización:

Aún tengo el problema. A veces, cuando la máquina se encuentra en mal estado, tengo ventanas de terminal abiertas que ya han iniciado sesión correctamente y que puedo usar para depurar.

Muchos comandos no se ejecutan correctamente, pero todos muestran un patrón de problemas para escribir (para stdout, creo). Por ejemplo, cuando corro ls -al, veo ls: write erroremitido a stderr. Cuando corro ls -al > /dev/null, no se imprime nada en stderr.

Es importante tratar el problema real y no solo el síntoma. Por lo tanto, pruebe las siguientes sugerencias y actualícelas, ya que pueden sugerir otras soluciones.

1. ¿Qué usuario posee el terminal? :
   Mi primer presentimiento es que esto puede estar relacionado con la configuración de su cuenta. Si la terminal está intentando acceder a los recursos o directorios que solo el usuario administrador puede (si la suya es una cuenta no administrativa), eso puede conducir a un estado de congelación, no permitiéndole acceder a la terminal. Así que adelante y asegúrese de que cuando comience una sesión de terminal, sea local para su usuario y no para otro usuario. El hecho de que no puedas crear un proceso de sudo me está apuntando a esta dirección.

2. Escriba Control-Z o Comando-Z:
   esta secuencia de teclas de control suspende un programa que puede estar ejecutándose y le da un indicador de shell. Ahora puede ingresar el comando jobs para encontrar el nombre del programa, luego reiniciar el programa con fg o terminarlo con kill.

3. Presione Comando-C :
   Esto se interrumpirá si el terminal está intentando ejecutar un programa en segundo plano. Pruébalo un par de veces. Tenga en cuenta si ve alguna salida

4. Escriba Control-Q :
   si la salida se ha detenido con Control-S, esto lo reiniciará.

5. Obtenga un shell alternativo :
   si desea probar un shell diferente durante unos días, sus comportamientos a veces pueden ayudarlo a comprender el problema con Terminal dado si actúan de cierta manera. Consulte estos enlaces a continuación para ver alternativas

https://git-scm.com/downloads/guis
https://computers.tutsplus.com/tutorials/beyond-terminal-4-os-x-terminal-alternatives--mac-56217

Ayudará a saber lo siguiente, si no se menciona ya:

• ¿Cómo estás iniciando la sesión terminal? ¿Es esto a través de Spotlight o un icono de escritorio o de alguna otra manera?

• ¿Qué hace la terminal cuando se cuelga? ¿Está en el medio de ejecutar un comando (el mismo comando cada vez antes de que se cuelgue) o simplemente se cuelga desde el momento en que inicia una sesión de terminal / ventanas.

• ¿Para qué sueles utilizar tu terminal? Si la mayoría de su uso es solo para comandos relacionados con git, sugeriría usar Something like Github para Mac, ya que generalmente puede hacer la mayoría de las cosas desde allí.

Intentaría deshabilitar SIP y dtrace login para encontrar la causa raíz (para deshabilitar y volver a habilitar SIP, consulte http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac -os-x / )

$ csrutil status
System Integrity Protection status: disabled.
$ cp /usr/bin/login /tmp
$ sudo dtruss /tmp/login

Intentando darle un ejemplo de salida, descubrí que las cosas son mucho más simples de lo que pensaba. No es necesario deshabilitar SIP, solo copie el inicio de sesión.

dtuss devolverá las llamadas al sistema y podría dar una pista de dónde van las cosas mal.

cp /usr/bin/login .
sudo ls

da tu contraseña Entonces hazlo

sudo dtruss -d -e ./login 2> dtruss_login.txt

ingrese su nombre de usuario, presione enter

ingrese su contraseña, presione enter

ingrese 'salir', presione enter

y finalmente cargue dtruss_login.txt a, por ejemplo, https://gist.github.com/

Puede copiar el contenido del archivo al portapapeles de esta manera

cat dtruss_login.txt | pbcopy

Puede encontrar un ejemplo de inicio de sesión aquí: https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

El segundo entero en cada línea es el tiempo que tomó la llamada.

Por supuesto, sería genial si pudieras ejecutar esto cuando se cuelgue el inicio de sesión, pero si te entiendo bien, esto es imposible ... tal vez tú u otra persona tengan una idea sobre cómo 'iniciar sesión' cuando el terminal se cuelga ?

El logincódigo fuente del comando ha sido publicado por Apple. El sitio web es macOS 10.13.3 Source . La única descarga requerida es system_cmds-790.30.1. Una vez descargado, el proyecto se puede modificar fácilmente para construir solo el logincomando. El proyecto modificado y el logincomando se colocaron en GitHub en davidanderson61 / system_cmds-10.13.3 .

La idea aquí es modificar loginpara escribir información de depuración en la consola. Esto ayudaría a determinar por qué se loginbloquea el comando. Las modificaciones se pueden hacer a cualquiera que desee participar. Asumí que este habría sido yo.

Instalar el logincomando de depuración .

1. Seleccione la última versión del sitio web davidanderson61 / system_cmds-10.13.3 / releases .

2. Descargue el logincomando de depuración en su Downloadscarpeta. En "Activos", haga clic derecho loginy seleccione "Descargar archivo vinculado como", luego seleccione "Guardar".

3. Parcialmente, deshabilite la Protección de integridad del sistema (SIP). El comando se da a continuación. Antes de ingresar el comando, deberá iniciar en un MacOS Recover , luego en una ventana de Terminal.

   csrutil  enable  --without  fs

4. Ingrese el comando dado a continuación para guardar el logincomando original . Si login.orignalya existe, puede omitir este paso.

   sudo  mv  /usr/bin/login  /usr/bin/login.original

5. Ingrese los comandos dados a continuación para copiar el logincomando de depuración y establecer los permisos adecuados.

   sudo  cp  ~/Downloads/login  /usr/bin/login
   sudo  chmod  104555  /usr/bin/login

6. Habilite la Protección de integridad del sistema (SIP). Ingrese el siguiente comando. Luego, debe reiniciar.

   sudo  csrutil  clear

Configurar la aplicación de consola

A continuación se detallan los pasos para configurar la aplicación Consola para mostrar solo los mensajes del logincomando.

1. Abre la aplicación de consola.

2. Agregue una PIDcolumna, como se muestra a continuación.

   

3. Ingrese loginen el campo de búsqueda.

   

   Mientras el campo de búsqueda tiene el foco, presione la returntecla. El campo de búsqueda debería cambiar a lo que se muestra a continuación.

   

4. Cambie Anya Process, como se muestra a continuación.

   

5. Cambio de lista Containsa Equals, como se muestra a continuación.

   

6. Selecciona el Savebotón. Cuando se le solicite "Guardar búsqueda como:", ingrese Login, luego seleccione Save.

   

Los resultados deberían aparecer como se muestra a continuación. La próxima vez que abra la aplicación Consola, solo tendrá que seleccionar el botón "Iniciar sesión".

Apéndice

Cómo se creó el repositorio de GitHub.

1. Haga clic en el system_cmds.xcodeprojarchivo abierto en Xcode.
2. Desde la barra de menú, seleccione Source Control->Create Git Repositories....
3. Desde la barra de menú, seleccione Product->Scheme->New Scheme.... A continuación, seleccione logincomo destino y nombre.
4. Desde la barra de menú, seleccione Project->Build.
5. Salga de Xcode.
6. Inicie sesión en GitHub y cree un nuevo repositorio.
7. En la parte superior de la página de Configuración rápida de su repositorio GitHub, haga clic para copiar la URL del repositorio remoto.

8. Para una ventana de aplicación de Terminal, ingrese el siguiente comando. Reemplazar <remote repository URL>con URL copiada en el paso anterior.

   git  remote  add  origin  <remote repository URL>

9. Abra el proyecto en Xcode y desde la barra de menú, seleccione Source Control->Push....

Cómo se creó la primera versión

1. Desde una ventana de la aplicación Terminal, ingrese los siguientes comandos.

   git  tag  -a  v1.0  -m  "Original source code"
   git  push  origin  v1.0

2. Copie el logincomando integrado a su Downloadscarpeta.

3. Desde su cuenta de GitHub, cree una nueva versión como v1.0. Adjuntar ~/Downloads/logincomo un binario.

También tuve este problema al ejecutar la consola sbt en emacs. Cada vez que salía de la consola sbt simplemente matando la ventana en lugar de salir de la consola sbt "muy bien", causaba que un proceso de Java se bloqueara incluso después de cerrar la ventana, y de alguna manera evitaba que se crearan nuevas sesiones de terminal. Eliminé a la fuerza el proceso de Java desde el monitor de actividad, y el terminal colgante realmente se inició, desde dentro de emacs, así como en una nueva pestaña.

Ahora, solo me aseguro de salir bien usando el comando exito ctrl-d(o ctrl-c ctrl-den emacs term/multi-term), luego mato la ventana.

1. Comprueba si tu proceso se cuelga realmente durante login
2. Eche un vistazo al Monitor de actividad y rootesté atento a los procesos (es decir, nano, emacs, vim) que podría haber iniciado y que no se cerró correctamente (bloquearse, acaba de matar el terminal, etc.) y que todavía se están ejecutando.
3. Elimine este proceso (s) y el inicio de sesión debería funcionar de inmediato.

Solo mis dos centavos.

He instalado el paquete Terminus para Sublime Text, que me permite ejecutar la terminal dentro de mi editor de texto.

Cerrar Sublime Text de inmediato permitió que mi terminal comenzara a funcionar nuevamente.

FWIW, tuve este mismo problema. Se resolvería después de reiniciar, pero quería ahorrar el tiempo de hacerlo varias veces al día. Comenzó después de usar un entorno particular de nodeJS, así que entré en el monitor de actividad y noté un proceso de nodo en curso. Matar esa instancia resolvió el problema para mí, por lo que si alguien que experimenta esto recientemente comenzó a trabajar con node o npm localmente, ese podría ser su problema.

Matar una instancia nvim perdida me arregló esto. Supongo que esto no es específico de nvim, pero algo que estaba haciendo en mi caso causó problemas. Buscaría una aplicación de terminal huérfana fuera de lugar en el monitor de actividad y la mataría si la encuentra.