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.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
up vote 7 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

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
This issue was fixed before Debian 7 Wheezy has been released. It is though present in the according upstream releases or git snapshots. See bugs.debian.org/683228 – Axel Beckert Dec 18 '14 at 15:50
This just happened to me today on an older Centos 6 install. Thanks! – gubblebozer Aug 11 '15 at 13:57

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.

share|improve this answer
What should I do if it has no parent process? – d33tah Dec 15 '15 at 13:44

Your Answer


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.