Lo schermo GNU si blocca nel tentativo di ricollegarlo

Ho diverse sessioni di schermate GNU di lunga durata. Ssh sulla scatola su cui sono in esecuzione e corro screen -d -r fooper staccarli se sono collegati altrove, e quindi collegarli nella mia finestra corrente.

Il 99% delle volte funziona bene, ma a volte ottengo questo:

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

... e non succede nulla; Non posso assolutamente tornare alla shell. Provare in un'altra finestra fa la stessa cosa, l'unica cosa che posso fare è distruggere quella sessione dello schermo (perdendo tutti i programmi che la stavano eseguendo) e ricrearla

Perché succede? Come posso evitarlo o riconnettermi correttamente quando succede?

Modifica : Mio .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

Modifica : la fine di un straceregistro quando si tenta di allegare:

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

Non sono sicuro che avessi lo stesso problema, ma a volte ho lo stesso comportamento dello schermo ogni volta che la rete veniva accidentalmente disconnessa.

Dopo un po '(circa 10-15 minuti) lo schermo è di nuovo disponibile per la riconnessione. Dopo alcune invetigazioni, ho trovato una piccola nota nella pagina man:

   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.

Può essere che possa aiutare qualcuno, perché questa è l'unica pagina sul blocco dello schermo dopo che Google mi ha disconnesso.

La sessione dello schermo è probabilmente sospesa in attesa dello pseudo-terminale della shell con cui è stato collegato per ultimo allo schermo. A volte una connessione persa lascia quel guscio intorno e lo schermo deve timeout per staccarsi da esso.

Se esegui ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, dovresti vedere che è il punto di partenza della precedente sessione di shell.

Una volta terminata la sessione bash / shell a cui ti eri collegato, sarai in grado di ricollegarti.

# 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

In questo caso, il processo di eliminazione 23214 rilascerà la sessione dello schermo e sarà possibile ricollegarlo.

Lo schermo è stato aggiornato da quando sono state avviate quelle sessioni dello schermo?

Non riesco a ricordare i dettagli esatti, ma ricordo che circa un mese o tre fa, uno apt-get dist-upgradeschermo (a debian sid) aggiornato sul mio sistema e il postinst mi avvisarono di un aggiornamento incompatibile. Una copia del vecchio schermo era stata conservata (da qualche parte sotto / tmp IIRC) per consentire il ricollegamento alle vecchie sessioni, ma si raccomandava di ucciderle e riavviarle.

I sintomi che segnali sembrano simili a quelli che ho visto quando ho cercato di ricollegarmi accidentalmente a una vecchia sessione dello schermo con il nuovo / usr / bin / screen.

Forse è stato questo, da dpkg.log a giugno:

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