Re: screen refusing to reattach

[Joakim Ahlén]

Hi everyone,

I have been experiencing this bug for i guess a year or two and im dead
tired of it. Apparently others have the same problem. From reading this
thread and combining it with my own experience about it, my conclusion of
the problem is:

* You use SSH to connect to a machine in which you run screen
* Your network conection dies without the SSH connection being killed (from
the servers point of view)
* When you start up a new SSH trying to reconnect to the screen, the pty is
busy from the last SSH client process which haven't died since it still
thinks there is an active SSH connection.
* Screen reattach does not work and hangs indefinitely

One question, though, is why this doesn't happen if you just start two
parallell SSH connections and reattaches one from the other. I have no
answer to this.

However, i do have a foolproof way of getting back control of the screen. It
may sound really obscure - but it works EVERY time.

* Run screen -d -r, which hangs. Leave it hanging.
* Start up another SSH session, and su to root
* Find the PID of the SCREEN-process (with capitals), and run "strace -p
[pid of SCREEN] 2>/dev/null"
* The "screen -d -r" will now work again, and reattach to your screen.
* From within your screen, su to root, find the PID of the strace-process
you just started and run "kill [pid of strace]; strace -p [pid of SCREEN]
2>/dev/null"
* Simply break this command after you run it. Exit the other SSH-window.

Voila!

I'm not too familiar with ptys/terminals and whatever so i have no idea how
this really works, but it does. It would be fun if someone could explain
why.

Has anyone tried the patch from
http://savannah.gnu.org/bugs/download.php?item_id=11610&item_file_id=2120?
Does it work? If not, i hope someone else can fix this bug soon since i'm
getting really tired of it.

Regards

Joakim Ahlén

> Jeremy/all,
>
> > Yes, kill off the shell associated with the pty/tty running "screen".  I
> > found that killing off screen by itself doesn't cut it...
>
>
> Okay, this just happened to me again, and Jeremy's suggestion didn't do
the trick. I thought I'd take a moment while this was fresh in my mind to
describe ANAICT the exact sequence of events.
> 1) The window I'm currently working in locks up. On this particular
occasion I had been away from the term, but only for a minute or so.
> 2) I can switch to other windows and they appear to be responding
correctly.
> 3) I return to the locked up window and kill it. I get the "do you really
want to kill this window prompt". I hit 'y'. The window disappears, but then
screen is locked (with the "do you really" prompt still there). "Locked" in
this case means no key appears to do anything.
> 4) I kill the term.
> 5) In a new term, I check the processes. I have one screen -s running in
an Eterm (that's on the base machine), two screen -x's running in -tcsh's
(from who knows where), and one orphaned screen -x (presumably the one I was
just running here on my off-site machine). (That's not including the screen
processes related to my completely separate screen session, which is never
impacted by the first session crashing horribly.) Oh, and also of course one
SCREEN.
> 6) I kill the orphan screen -x first, then kill the -tcsh's that are
parenting the other screen -x's, then kill the freshly orphaned screen -x's.
The -tcsh's require kill -9's (typical for a login shell IME), but the
screen processes go nicely.
> 7) Try to reconnect with screen -x, no go. Now kill the Eterm and the
screen -s as well. Try screen -x, screen -d, screen -D, and screen -DD; all
just hang (but respond to Ctrl-C). A screen -ls shows the session is
"attached".
> 8) Sighly dramatically, kill -9 the SCREEN. This removes the session from
screen -ls and I can start fresh with a new screen -s.
> So does anyone have any thoughts on why this occurs and how to stop it?