Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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
share|improve this question
    
posting your ~/.screenrc (and maybe /etc/screenrc if it is customized) could be helpful –  user2387 Aug 29 '12 at 9:06
    
Please post the output of strace screen -d -r foo (you may need to make a non-set[ug]id copy of the screen executable) and strace -p$(pidof SCREEN) around the time of a failed reconnection. –  Gilles Aug 29 '12 at 22:47
    
@Gilles It just happened again; I added the strace log. straceing the main screen process shows a similar block in a write() call –  Michael Mrozek Sep 11 '12 at 2:24
    
It seems to happen when the previously connected screen wasn't disconnected cleanly (in this case I had it attached from another computer which then lost its network connection). Could screen be trying to write to a connection that no longer exists? –  Michael Mrozek Sep 11 '12 at 2:26
    
Is the main screen process (the one called SCREEN) still alive? What is it doing (strace)? –  Gilles Sep 11 '12 at 7:13
show 2 more comments

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
I don't exactly understand how based on that man page entry, but this did fix it for me. I set nonblock 5 a while ago, and just ran into the issue again, and after 5 seconds it suddenly attached normally –  Michael Mrozek Jun 20 '13 at 20:30
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.