11

I use putty and have an unreliable wireless connection, so I use screen to keep my work going. Often I'll get disconnected, and then I can't reattach my screen. I'll run screen -D -RR and it will just sit there indefinitely. I've tried ctrl+z to get my console back, followed by ps aux | grep screen and then kill -9 for all results, and then screen -D -RR again but I get the same results. I try any combination of d's and r's you care to mention, but still it just sits there. My screen is there, it just won't do anything, least of all resume.

Anybody have any tips or tricks or ideas for how to get my screen session to resume?

15

I've seen this when I drop a connection to an active screen then reconnect. Bug #27462 ("Reconnect stalls when original session is lost") describes the problem as I see it. What appears to happen is that screen is trying to notify the tty that holds it that it is about to leave, but since the tty is hung due to a dropped connection it has to wait for the timeout to happen (which is upwards of five minutes in some cases).

To fix it, I do this:

  • figure out which tty is holding on to the screen session ps -ef | grep screen | grep pty
  • find the login bash that is associated with that tty ps -ef | grep bash | grep $PTY
  • kill that bash kill -KILL $PID

This causes screen to complete its disconnect correctly, and lets you reconnect normally.

See here for an example script automating this somewhat.

  • ps -ef | grep screen | grep tty never prints anything because ps -ef | grep screen never returns anything with the string tty. – Dave Aaron Smith Jan 22 '10 at 22:18
  • Actually the example script seems to do the trick. Thanks! – Dave Aaron Smith Jan 22 '10 at 22:24
  • 1
    Yeah, I meant 'pty', not 'tty'. – David Mackintosh Jan 23 '10 at 2:59
2

I had a similar issue with my screen sessions. I name them and have them setup as multi-user sessions. What I found was that it was listing my sessions but telling me I had none to reconnect to. Then I tried:

screen -x <session_name>

It worked like a champ!

1

I can't say I've ever had a problem with screen not coming back, no matter what type of connection I'm on. My usual method:

ssh myname@foo
screen -S sessionName
(do my work... get disconnected...)

ssh myname@foo
screen -d (just to make sure anything wasn't left attached)
screen -r sessionName
  • 1
    For example screen -list returns 32322.mySession (Attached). Then I screen -d mySession. Then screen -list still returns 32322.mySession (Attached), and screen -r mySession returns There is no screen to be resumed matching daveSession. – Dave Aaron Smith Jan 22 '10 at 22:03
  • did you try just "screen -d"? – Jason Antman Jan 25 '10 at 20:37
0

Is it possible that this bug is affecting you?

http://savannah.gnu.org/bugs/?27462

Can you try doing the workaround they recommend and seeing if it works?

  • The workaround didn't make much sense to me. My output of ps -ef |grep screen doesn't look like the example at all. – Dave Aaron Smith Jan 22 '10 at 22:17
0

Soulrce:https://kb.iu.edu/data/ahrm.html

To see your existing screen sessions, enter:
  screen -list
This will display a list of your current screen sessions. For instance, if you had one attached screen, you would see:

         1636.pts-21.hostname      (Attached)

To detach an attached screen, enter:
  screen -D
If you have more than one attached screen, you can specify a particular screen to detach. For example, to detach the screen in the above example, you would enter:
  screen -D 1636.pts-21.hostname
0

If you're smart like me, you were trying to resume a screen session started as root with the regular user account. Found this out with ls /var/run/screen showing me a directory for root

0

I occasionally have the same problem (screen -r -d not resuming, non-responsive). To fix, find the terminal (tty/pty) associated with the screen session:

screen -list
There is a screen on:
    28176.pts-51.localhost        (Attached)
1 Socket in /tmp/uscreens/S-xxxx.

Find the terminal listed (in this example pts-51) :

ps axuw | grep 'pts/51'   # will vary depending upon how pty's are named
you     12293  0.0  0.2  2148 1128 pts/51   Ss   10:34   0:00 -bash

Kill the processes on that terminal (usually your shell) :

kill 12293

run ps again to make sure it is gone. If not :

kill -9 12293

On my server (gnu/linux), I sometimes will have to kill -9 several times until it dies.

After all the processes on that tty are gone, screen should resume correctly:

screen -r -d
-1

Remove dead screens with screen -wipe.

  • I think that's the exact opposite of what he's trying to do. – Chris S May 3 '12 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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