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 9


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.

  • 2
    Tried all options(-RD, -xr) mentioned here and could not recover the session. Ended up killing the SCREEN session by finding (ps -ef | grep bash) it.
    – so_mv
    May 24, 2012 at 9:16

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

  • 2
    i have a similar issue, but screen -RD <name> still hangs ... :-(
    – harald
    Jan 19, 2011 at 10:28

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
  • How to send a SIGCHILD?
    – giorgio79
    Mar 10, 2013 at 11:34
  • 1
    Use the scarily named kill command like so: kill -s SIGCHLD <PID> where <PID> is the Process ID number (left-most column in my example output)
    – RobM
    Mar 28, 2013 at 19:03

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.

  • A kill spree of processes under the screen was the only thing that saved me as well. I'd rather lose many processes under the screen, than lose the whole screen session!
    – Yonatan
    Jun 3, 2017 at 8:15
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.

You must log in to answer this question.

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