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
  • posting your ~/.screenrc (and maybe /etc/screenrc if it is customized) could be helpful
    – user2387
    Commented Aug 29, 2012 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. Commented Aug 29, 2012 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 Commented Sep 11, 2012 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? Commented Sep 11, 2012 at 2:26
  • Is the main screen process (the one called SCREEN) still alive? What is it doing (strace)? Commented Sep 11, 2012 at 7:13

3 Answers 3


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.

  • 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 Commented Jun 20, 2013 at 20:30
  • is there a way to update the config without killing the process? Commented Feb 14, 2021 at 13:50

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.

  • 3
    What should I do if it has no parent process?
    – d33tah
    Commented Dec 15, 2015 at 13:44
  • This one helped for me today, killing the sshd made screen responsive again! Hours and hours of work saved!
    – user230910
    Commented Aug 22, 2019 at 0:07

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

  • 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 Commented Dec 18, 2014 at 15:50
  • This just happened to me today on an older Centos 6 install. Thanks! Commented Aug 11, 2015 at 13:57
  • I was just bitten by this on Gentoo, I was upgrading from 4.3 to 4.4.
    – jlh
    Commented Feb 25, 2017 at 15:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .