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.

Community
  • 1
Viktor Rosenfeld
  • 170
  • 1
  • 7
  • 3
    What does `screen -ls`says in those "hanging" cases ? `screen -d -r `means "detach and recover" so not having detached it first-hand shouldn't matter. (And for doing it often, it doesn't...) – mveroone Dec 02 '13 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 03 '13 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 06 '13 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 '13 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 '14 at 11:21
  • @MatthiasUrlichs Ultimately, I want to reattach to the screen session. Simply killing PID 7387 will not let me reattach to PID 15299. – Viktor Rosenfeld Jan 24 '14 at 12:55
  • Right, current `screen` still thinks you're attached after you kill the client, which arguably is a bug. – Matthias Urlichs Jan 24 '14 at 14:52

3 Answers3

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.

pacifist
  • 181
  • 6
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.

Viktor Rosenfeld
  • 170
  • 1
  • 7
-2

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

http://mosh.mit.edu

Fred Concklin
  • 97
  • 1