GNU screen - Unable to reattach to screen after lost connection

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

screen -r 4033

screen -x 7728

Answer 9

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.