La pantalla de GNU se congela al intentar volver a conectar

Tengo varias sesiones de pantalla GNU de larga duración. Me dirijo a la caja en la que se están ejecutando y corro screen -d -r foopara separarlos si están conectados en otro lugar, y luego los adjunto en mi ventana actual.

El 99% de las veces esto funciona bien, pero en ocasiones obtengo esto:

$ screen -d -r foo
[2430.foo detached.]

... y no pasa nada; No puedo volver a la cáscara en absoluto. Intentar en otra ventana hace lo mismo, lo único que puedo hacer es destruir esa sesión de pantalla (perder todos los programas que se estaban ejecutando en ella) y recrearla

¿Por qué pasó esto? ¿Cómo puedo evitarlo o volver a conectarme con éxito cuando sucede?

Editar : Mi .screenrc:

startup_message off
defwritelock off
bind q quit
caption always '%{gk}   (%n) %t                   %{y}%d %M %Y :: %c:%s                   %{b}%W%{d}'
screen -t ZSH
autodetach on
shelltitle ZSH
defutf8 on

Editar : el final de un straceregistro al intentar adjuntar:

readlink("/proc/self/fd/0", "/dev/pts/14", 4095) = 11
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/dev/pts/14", O_RDWR|O_NONBLOCK)  = 3
geteuid32()                             = 1000
getegid32()                             = 1000
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
umask(0)                                = 022
lstat64("/var/run/screen", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
access("/var/run/screen/S-mrozekma", F_OK) = 0
stat64("/var/run/screen/S-mrozekma", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
umask(022)                              = 0
uname({sys="Linux", node="etudes-2", ...}) = 0
rt_sigaction(SIGHUP, {0x806e520, [], 0}, {SIG_DFL, [], 0}, 8) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/var/run/screen/S-mrozekma", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 6 entries */, 32768)     = 124
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/var/run/screen/S-mrozekma/2386.chat", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 1000
getegid32()                             = 1000
fcntl64(4, F_SETFL, O_RDONLY)           = 0
geteuid32()                             = 1000
getegid32()                             = 1000
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
geteuid32()                             = 1000
getegid32()                             = 1000
setuid32(1000)                          = 0
setgid32(1000)                          = 0
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
getpid()                                = 30081
write(4, "\0gsm\4\0\0\0/dev/pts/14\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336

No estoy seguro si tuve el mismo problema que usted, pero a veces tengo un comportamiento de pantalla similar cada vez que la red se desconecta accidentalmente.

Después de un tiempo (unos 10-15 minutos) la pantalla vuelve a estar disponible para la reconexión. Después de algunas investigaciones, he encontrado una pequeña nota en la página del manual:

   nonblock [on|off|numsecs]

   Tell  screen  how to deal with user interfaces (displays) that cease to
   accept output. This can happen if a user presses ^S or a TCP/modem con‐
   nection gets cut but no hangup is received. If nonblock is off (this is
   the default) screen waits until the display restarts to accept the out‐
   put.  If  nonblock is on, screen waits until the timeout is reached (on
   is treated as 1s). If the display  still  doesn't  receive  characters,
   screen will consider it "blocked" and stop sending characters to it. If
   at some time it restarts to accept characters, screen will unblock  the
   display and redisplay the updated window contents.

Puede ser que ayude a alguien, porque esta es la única página sobre congelaciones de pantalla después de la desconexión que Google me dio.

Su sesión de pantalla probablemente se cuelgue esperando el pseudo-terminal del shell con el que se conectó por última vez a la pantalla. A veces, una conexión perdida deja ese caparazón y la pantalla tiene que agotar el tiempo de espera para desconectarse.

Si ejecuta ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, debería ver que son los puntos de la sesión de shell anterior.

Una vez que elimine la sesión de bash / shell con la que se había conectado, podrá volver a adjuntarla.

# ps auwxf|grep -B2 screen
root     23214  0.0  0.0 109304  4016 ?        Ssl  19:13   0:00  \_ sshd: root@pts/6 
root     23566  0.0  0.0 117400  2272 pts/6    Ss   19:13   0:00      \_ -bash
root     10445  0.0  0.0 125156  1156 pts/6    S+   19:23   0:00          \_ screen -ADR MYSCREEN

En este caso, el proceso de eliminación 23214 liberará la sesión de pantalla y podrá volver a conectarla.

¿Se ha actualizado la pantalla desde que se iniciaron esas sesiones de pantalla?

No puedo recordar los detalles exactos, pero sí recuerdo que hace aproximadamente un mes o tres, una apt-get dist-upgradepantalla actualizada (para debian sid) en mi sistema y la última vez me advirtieron sobre una actualización incompatible. Se había guardado una copia de la pantalla anterior (en algún lugar debajo de / tmp IIRC) para permitir volver a conectar las sesiones antiguas, pero se recomendó matarlas y reiniciarlas.

Los síntomas que informas son similares a los que vi cuando accidentalmente intenté volver a conectarme a una sesión de pantalla anterior con la nueva / usr / bin / screen.

Posiblemente fue esto, desde dpkg.log en junio:

2012-06-14 08:11:51 upgrade screen:amd64 4.0.3-14 4.1.0~20120320gitdb59704-2