16

I have previously reattached to a long-running screen session with screen -dr control. However, sometimes this command will not reattach to the screen and instead hang forever (10+ minutes after which I aborted). This only happens when the SSH connection is dropped unexpectedly and not when the screen is properly detached with Ctrl-A d. Other switches, such as screen -x or screen -D -RR also do not work.

This post suggests to kill the PTY that holds the screen session which will cause screen to complete its disconnect. However, it simply kills the shell from which screen -dr control was called.

For example:

$ ps -ef | grep control | grep -v grep
nomad     7387  7109  0 13:05 pts/50   00:00:00 screen -dr control
nomad    15299     1  0 Nov27 ?        00:13:47 SCREEN -S control

$ ps -ef | grep bash | grep 'pts/50'
nomad     7109  7108  0 12:49 pts/50   00:00:00 -bash

The linked post suggest to kill the bash process with PID 7109. This will also kill the screen -dr control process with PID 7387. Afterwards, I still cannot connect to the screen.

The process SCREEN -S control which started the screen session has init as its parent which I obviously cannot kill.

Is there a way to reattach to the hung screen session?

Update: This happens on CentOS 6.4 using kernel 2.6.32-358.6.1.el6.x86_64. The shells are all bash version 4.1.2(1)-release.

Improve this question
7
  • 3
    What does screen -lssays in those "hanging" cases ? screen -d -r <session>means "detach and recover" so not having detached it first-hand shouldn't matter. (And for doing it often, it doesn't...)
    – mveroone
    Dec 2, 2013 at 23:07
  • Try running lsof on the screen processes, see if there is something "stuck." Screen uses a unix socket to communicate between processes, likely something has kept it open. Also make sure that the socket hasn't gotten deleted or its ownership changed or something. In general you should also include what OS and version you are using, although I don't have anything particular in mind that would be os-dependent this time around.
    – Dan Pritts
    Dec 3, 2013 at 17:50
  • 3
    Are you ssh'ing via another hop, e.g. using netcat as a proxy command? In this case I have had the problem where the ssh connection to the first box drops, but the netcat proxy command keeps a 'second' ssh connection open. the -d should work however.
    – Jens Timmerman
    Dec 6, 2013 at 14:00
  • Jens, your advice did the trick. I did indeed proxy through netcat and killing it on the intermediate host enabled me to reattach to the screen.
    – Viktor Rosenfeld
    Dec 20, 2013 at 19:47
  • Why would you want to kill the hung screen command's parent process? You want to kill the attaching screen command itself. #7387 in your case.
    – Matthias Urlichs
    Jan 24, 2014 at 11:21

3 Answers 3

Reset to default
5

I think you should try 

screen -DR

next time too - the angry (uppercase) invocation should force it to disconnect that other session being held by your intermediate netcat hop.

Improve this answer
3
  • I tried this, it does not work. Killing the netcat proxy does the trick.
    – Viktor Rosenfeld
    Jan 1, 2014 at 2:57
  • Strange. It should. What does happen instead?
    – Matthias Urlichs
    Jan 24, 2014 at 14:52
  • All further invocations of screen (-dr, -x, -DR) hang forever. Once I've killed the netcat proxy, these invocations work again.
    – Viktor Rosenfeld
    Jan 25, 2014 at 16:55
1

As suggested by Jens Timmerman, the ultimate reason for this strange behavior was that I was connecting to the remote server using SSH ProxyCommand and ncat. After killing the ncat on the intermediate machine, I am able to reattach to the screen session.

Improve this answer
-2

If this is a frequent issue you could also consider using mosh as an ssh replacement:

http://mosh.mit.edu

Improve this answer

You must log in to answer this question.

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