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? _______________________________________________ screen-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/screen-users
