Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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...) –  Kwaio Dec 2 '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 3 '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 6 '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 at 11:21
show 2 more comments

2 Answers

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.

share|improve this answer
    
I tried this, it does not work. Killing the netcat proxy does the trick. –  Viktor Rosenfeld Jan 1 at 2:57
    
Strange. It should. What does happen instead? –  Matthias Urlichs Jan 24 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 at 16:55
add comment

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

http://mosh.mit.edu

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.