L'écran GNU se bloque en essayant de le rattacher

16

J'ai plusieurs sessions d'écran GNU de longue durée. Je ssh dans la boîte sur laquelle ils s'exécutent et je cours screen -d -r foopour les détacher s'ils sont connectés ailleurs, puis les attacher dans ma fenêtre actuelle.

99% du temps, cela fonctionne bien, mais à l'occasion, j'obtiens ceci:

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

... et rien ne se passe; Je ne peux pas revenir du tout sur la coquille. Essayer dans une autre fenêtre fait la même chose, la seule chose que je peux faire est de détruire cette session d'écran (en perdant tous les programmes qui y étaient en cours d'exécution) et de la recréer

Pourquoi cela arrive-t-il? Comment puis-je l'éviter ou me reconnecter avec succès lorsque cela se produit?


Modifier : Mon .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

Modifier : la fin d'un stracejournal lorsque vous essayez de joindre:

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
Michael Mrozek
la source
publier votre ~ / .screenrc (et peut-être / etc / screenrc s'il est personnalisé) pourrait être utile
user2387
Veuillez publier la sortie de strace screen -d -r foo(vous devrez peut-être faire une copie d'ID [ug] non définie de l' screenexécutable) et aux strace -p$(pidof SCREEN)alentours de l'échec d'une reconnexion.
Gilles 'SO- arrête d'être méchant'
@Gilles C'est arrivé à nouveau; J'ai ajouté le stracejournal. straceLe processus de l'écran principal montre un bloc similaire dans un write()appel
Michael Mrozek
Cela semble se produire lorsque l'écran précédemment connecté n'a pas été déconnecté proprement (dans ce cas, je l'ai attaché à un autre ordinateur qui a ensuite perdu sa connexion réseau). Vous screenessayez peut- être d'écrire sur une connexion qui n'existe plus?
Michael Mrozek
Le processus de l'écran principal (celui appelé SCREEN) est-il toujours actif? Que fait-il ( strace)?
Gilles 'SO- arrête d'être méchant'

Réponses:

8

Je ne sais pas si j'ai eu le même problème que vous, mais j'ai parfois le même comportement d'écran chaque fois que mon réseau est accidentellement déconnecté.

Après un certain temps (environ 10-15 minutes), l'écran est à nouveau disponible pour la reconnexion. Après quelques vérifications, j'ai trouvé une petite note dans la page de manuel:

   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.

Peut-être que cela aidera quelqu'un, car c'est la seule page sur le gel de l'écran après la déconnexion que Google m'a donnée.

se ruer
la source
Je ne comprends pas exactement comment basé sur cette entrée de page de manuel, mais cela l'a corrigé pour moi. Je me suis installé il y a nonblock 5un certain temps, et je suis à nouveau tombé sur le problème, et après 5 secondes, il s'est soudainement attaché normalement
Michael Mrozek
6

Votre session d'écran est probablement bloquée en attendant le pseudo-terminal du shell avec lequel vous avez attaché l'écran en dernier. Parfois, une connexion perdue laisse ce shell autour et l'écran doit expirer afin de s'en détacher.

Si vous exécutez ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, vous devriez voir qu'il s'agit des points de la session shell précédente.

Une fois que vous avez tué la session bash / shell à laquelle vous vous êtes attaché, vous pourrez vous reconnecter.

# 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

Dans ce cas, le processus de suppression 23214 libérera la session d'écran et vous pourrez la rattacher.

ZachL
la source
3
Que dois-je faire s'il n'a pas de processus parent?
d33tah
Celui-ci m'a aidé aujourd'hui, tuant l'écran sshd à nouveau réactif! Des heures et des heures de travail économisées!
user230910
4

L'écran a-t-il été mis à niveau depuis le début de ces sessions d'écran?

Je ne me souviens pas des détails exacts, mais je me souviens qu'il y a environ un mois ou trois, un apt-get dist-upgradeécran (vers debian sid) mis à niveau sur mon système et le postinst m'a averti d'une mise à niveau incompatible. Une copie de l'ancien écran avait été conservée (quelque part sous / tmp IIRC) pour permettre de les rattacher aux anciennes sessions, mais il était recommandé de les tuer et de les redémarrer.

Les symptômes que vous signalez ressemblent à ce que j'ai vu lorsque j'ai accidentellement tenté de me reconnecter à une ancienne session d'écran avec le nouvel écran / usr / bin /.

C'était peut-être cela, de dpkg.log en juin:

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

cas
la source
Ce problème a été corrigé avant la publication de Debian 7 Wheezy. Il est cependant présent dans les versions en amont ou les instantanés git correspondants. Voir bugs.debian.org/683228
Axel Beckert
Cela m'est arrivé aujourd'hui avec une ancienne installation de Centos 6. Merci!
Mike Andrews
Je viens d'être mordu par cela sur Gentoo, je passais de 4.3 à 4.4.
jlh