GNU screen freezes trying to reattach

Question

I have several long-running GNU screen sessions. I ssh to the box they're running on and run screen -d -r foo to detach them if they're connected anywhere else, and then attach them in my current window.

99% of the time this works fine, but on occasion I get this:

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

...and nothing happens; I can't get back to the shell at all. Trying in another window does the same thing, the only thing I can do is destroy that screen session (losing all the programs that were running in it) and recreate it

Why does this happen? How can I avoid it or reconnect successfully when it does happen?

---

Edit: My .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

---

Edit: The end of an strace log when trying to attach:

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

Answer 1

Not sure if I had the same issue as you, but sometimes I've the similar screen behaviour every time I network was accidentaly disconnected.

After a while ( about 10-15 minutes ) screen is available again for reconnection. After some invetigations, I've found a small note in the man page:

   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.

May be it'll help somebody, cause this is the only page about screen freezes after disconnetion google gave me.

Answer 2

Your screen session is probably hung waiting for the pseudo-terminal of the shell that you last attached to the screen with. Sometimes a lost connection leaves that shell around and screen has to timeout in order to detach from it.

If you run ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, you should see that it is the pts of for the previous shell session.

Once you kill the bash/shell session that you had attached with, you will be able to re-attach.

# 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

I this case, killing process 23214 will release the screen session and you can reattach.

Answer 3

Has screen been upgraded since those screen sessions were started?

I can't recall the exact details but I do remember that about a month or three ago, an apt-get dist-upgrade (to debian sid) upgraded screen on my system and the postinst warned me about an incompatible upgrade. A copy of the old screen had been kept (somewhere under /tmp IIRC) to enable reattaching to old sessions, but killing and restarting them was recommended.

The symptoms you report sound similar to what I saw when I accidentally tried to reconnect to an old screen session with the new /usr/bin/screen.

It was possibly this, from dpkg.log back in June:

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