GNU screen - Unable to reattach to screen after lost connection

I was using irssi in screen but lost connection. After I ssh'd back in to the server, I can no longer attach to that screen. screen -ls shows that the screen is already attached.

I tried screen -D to force detach it, and it said detach but screen -ls still says it's attached. I tried screen -x and it just hangs there.

[sub@server ~]$ screen -ls
There are screens on: 4033.poe (Detached) 7728.irssi (Attached)
2 Sockets in /var/run/screen/S-sub.

What can I do now?

9 Answers

If you are trying to connect the 'Attached' screen, then run screen -xr irssi. The uppercase '-X' sends a command to one of the screen sessions, the lowercase '-x' option allows you to reconnect to an attached session. But you still need to give the session name since there is more than one.

I have cleared this behavior up in the past by killing the shell that started the screen session. Basically, killing all bash instances for my user that were not owned by screen.

1

You gave it a non-default name. Try this: screen -RD irssi

1

you can try:

#Reattach a session and if necessary detach it first.
screen -d -r 7728.irssi
#Reattach a session. If necessary detach and logout remotely first.
screen -D -r 7728.irssi

it's always a good idea use the full name pid.tty

screen is known for not being backwards-compatible between versions. If the version of screen was updated on the server, it might be possible that you cannot reattach to older screen sessions anymore.

In that case, you can either use the old SCREEN binary to reattach (provided your distribution package manager saved it somewhere), or kill the session altogether.

I have had some success by sending the GNU/screen process a SIGCHLD (which it normally receives when a window is closed), this forces it to touch (and possibly recreate) the socket file.

Also note that there are two ways to invoke the screen executable that only differ in case: SCREEN is the server-side component you are attempting to reconnect to, while screen is the client-side that shuffles data between your terminal and the server-side. So you might want to try killing the lower-case version...

For instance in the following you can see that my screen and SCREEN processes are not considered to be parent and child, indicating that I have attached to an existing session.

# ps fao pid,command
25070 SCREEN -U
25071 \_ vim +let &t_Co=256
25073 \_ -bash
25077 \_ -bash
...
18364 \_ sshd: username [priv]
18366 | \_ sshd: username@pts/17
18367 | \_ -bash 870 | \_ screen -U -x

Fresh sessions look more like this:

19645 | \_ screen -S MySession
19646 | \_ SCREEN -S MySession
19647 | \_ bash 1485 | | \_ python
19700 | \_ bash

2

This happened to me while I was using vi where the session froze and I disconnected. When attempting to reattach to screen using screen -Arx, the process would just hang.

There might be a similar child process running causing screen to hang. If you recall one in particular focus on that, otherwise to get a list of the child process running under your screen do:

ps ux -H

Which will show the nested child processes:

zwood 28481 0.0 0.0 101148 8844 ? Ss Oct07 1:36 SCREEN -S mysession
zwood 28482 0.0 0.0 67436 1744 pts/2 Ss+ Oct07 0:00 /bin/bash
zwood 28515 0.0 0.0 67556 1876 pts/4 Ss+ Oct07 0:00 /bin/bash
zwood 4498 0.0 0.0 67436 1772 pts/5 Ss Oct07 0:00 /bin/bash
zwood 2007 0.0 0.0 73604 1324 pts/5 S+ 15:47 0:00 vi /home/zwood/.bashrc.custom
zwood 14670 0.0 0.0 67436 1768 pts/13 Ss+ Oct14 0:00 /bin/bash
zwood 27002 0.0 0.0 67436 1720 pts/11 Ss+ Oct20 0:00 /bin/bash
zwood 24748 0.0 0.0 67432 1712 pts/14 Ss+ Oct21 0:00 /bin/bash

After killing the vi process that caused the problem in the first place, I was able to reattach the screen without any issue. Killing any previous processes that had reattached to screen is probably a good idea as well. Just use:

kill -9 <pid>

I don't know what screen is doing in internally, why vi caused screen to hang, nor why killing the vi process brought my screen back. I've ran into this problem with screen in the past and had tried what most folks were recommending in this thread with no luck. Finding this problem child process is the only thing that has worked for me and has worked consistently at that.

1

screen -r 4033
screen -x 7728

killall -9 sshd

It worked for me. I had 3 different screens, and I've lost 3 different ssh connections. After reconnect, the screens were still attached, I issued the command above... of course I've lost my current connection, but it was a fresh one. On next reconnect, every screen were detached.

Note, if you are a superuser then you should use the --user option to kill only your ssh daemons.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy