Pantalla GNU: no se puede volver a conectar a la pantalla después de perder la conexión

Estaba usando irssi en la pantalla pero perdí la conexión. Después de volver a ingresar al servidor, ya no puedo conectarme a esa pantalla. screen -ls muestra que la pantalla ya está conectada.

Intenté screen -D para forzar la desconexión, y decía detach pero screen -ls todavía dice que está adjunto. Intenté screen -x y simplemente se cuelga allí.

[sub@server ~]$ screen -ls 
There are screens on:
 4033.poe (Detached)
 7728.irssi (Attached)
2 Sockets in /var/run/screen/S-sub.

¿Qué puedo hacer ahora?

Si está intentando conectar la pantalla 'Adjunta', ejecute screen -xr irssi. La '-X' en mayúscula envía un comando a una de las sesiones de pantalla, la opción '-x' en minúscula le permite volver a conectarse a una sesión adjunta. Pero aún necesita dar el nombre de la sesión ya que hay más de uno.

He aclarado este comportamiento en el pasado al matar el shell que inició la sesión de pantalla. Básicamente, matar todas las instancias de bash para mi usuario que no eran propiedad de la pantalla.

Le diste un nombre no predeterminado. Prueba esto:screen -RD irssi

puedes probar:

#Reattach a session and if necessary detach it first.
screen -d -r 7728.irssi  

#Reattach a session. If necessary detach and logout remotely first.
screen -D -r 7728.irssi

siempre es una buena idea usar el nombre completo pid.tty

screenes conocido por no ser compatible con versiones anteriores. Si la versión de screense actualizó en el servidor, es posible que ya no pueda volver a conectar sesiones de pantalla anteriores.

En ese caso, puede usar el viejo binario SCREEN para volver a adjuntar (siempre que su administrador de paquetes de distribución lo haya guardado en algún lugar) o eliminar la sesión por completo.

He tenido cierto éxito al enviar al proceso GNU / screen un SIGCHLD (que normalmente recibe cuando se cierra una ventana), esto lo obliga a tocar (y posiblemente recrear) el archivo de socket.

También tenga en cuenta que hay dos formas de invocar el screenejecutable que solo difieren en el caso: SCREENes el componente del lado del servidor al que está intentando reconectarse, mientras que screenes el lado del cliente que baraja los datos entre su terminal y el lado del servidor. Por lo tanto, puede intentar matar la versión en minúsculas ...

Por ejemplo, en lo siguiente puede ver que mi screeny SCREENprocesos no se consideran padre e hijo, lo que indica que me he adjuntado a una sesión existente.

# ps fao pid,command
25070 SCREEN -U
25071  \_ vim +let &t_Co=256
25073  \_ -bash
25077  \_ -bash
...
18364  \_ sshd: username [priv]
18366  |   \_ sshd: username@pts/17
18367  |       \_ -bash
  870  |           \_ screen -U -x

Las sesiones nuevas se parecen más a esto:

19645  |  \_ screen -S MySession
19646  |      \_ SCREEN -S MySession
19647  |          \_ bash
 1485  |          |   \_ python
19700  |          \_ bash

Esto me sucedió mientras estaba usando vi, donde la sesión se congeló y me desconecté. Al intentar volver a conectar la pantalla usando screen -Arx, el proceso simplemente se bloquea.

Es posible que se esté ejecutando un proceso secundario similar que haga que la pantalla se cuelgue. Si recuerda uno en particular, enfóquese en eso, de lo contrario, para obtener una lista del proceso secundario que se ejecuta bajo su pantalla, haga lo siguiente:

ps ux -H

Lo que mostrará los procesos hijos anidados:

zwood    28481  0.0  0.0 101148  8844 ?        Ss   Oct07   1:36 SCREEN -S mysession
zwood    28482  0.0  0.0  67436  1744 pts/2    Ss+  Oct07   0:00   /bin/bash
zwood    28515  0.0  0.0  67556  1876 pts/4    Ss+  Oct07   0:00   /bin/bash
zwood     4498  0.0  0.0  67436  1772 pts/5    Ss   Oct07   0:00   /bin/bash
zwood     2007  0.0  0.0  73604  1324 pts/5    S+   15:47   0:00     vi /home/zwood/.bashrc.custom
zwood    14670  0.0  0.0  67436  1768 pts/13   Ss+  Oct14   0:00   /bin/bash
zwood    27002  0.0  0.0  67436  1720 pts/11   Ss+  Oct20   0:00   /bin/bash
zwood    24748  0.0  0.0  67432  1712 pts/14   Ss+  Oct21   0:00   /bin/bash

Después de matar el proceso vi que causó el problema en primer lugar, pude volver a conectar la pantalla sin ningún problema. Probablemente también sea una buena idea eliminar cualquier proceso anterior que se haya vuelto a conectar a la pantalla. Solo usa:

kill -9 <pid>

No sé qué está haciendo la pantalla internamente, por qué vi causó que la pantalla se bloqueara, ni por qué matar el proceso vi me devolvió la pantalla. Me encontré con este problema con la pantalla en el pasado y probé lo que la mayoría de la gente recomendaba en este hilo sin suerte. Encontrar este problema en el proceso secundario es lo único que me ha funcionado y que ha funcionado de manera consistente.

screen -r 4033

screen -x 7728

killall -9 sshd

Funcionó para mi. Tenía 3 pantallas diferentes, y he perdido 3 conexiones ssh diferentes. Después de volver a conectar, las pantallas todavía estaban conectadas, emití el comando anterior ... por supuesto, perdí mi conexión actual, pero era nueva. En la próxima reconexión, todas las pantallas se separaron.

Tenga en cuenta que si es un superusuario, debe usar la --useropción para matar solo a sus demonios ssh.