From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 Description of problem: I run screen remotely via ssh and run irssi irc client (doesn't matter what, this happens with anything). Then I detach it. When I attach it again via screen -x and ssh connection is cut out, but remote doesn't know about it (my local cable modem loses network connection), screen works for a short period of time (few seconds or minutes), then somehow stops reading (selecting) from socket (terminal) that irssi writes to, and irssi gets locked on write() call to this terminal. When ssh connection actually timeouts, irssi gets unlocked. Other screen windows are unaffected, the only one affected is the one that is active in the moment of connection break. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create ssh connection to remote host 2. Run screen with irc client and connect it somewhere (so the results are visible - irc client timeouts), but you can run anything. 3. Detach, reattach via "screen -x" 4. Somehow firewall your connection so that remote doesn't know about it. 5. Wait :) Actual Results: screen freezed. Expected Results: screen shouldn't freeze :-) Additional info:
Looking into this.
Apoligies for the long delay. I wasn't able to reproduce the specific behavior described, so I have a few questions: - When your connection 'hangs', is your cable modem getting renumbered (a new IP address)? - When the ssh connection is lost (the point at which screen moves from a frozen state to a normal state, allowing reattachment), is it because of a TCP timeout? - Are you killing the ssh connection on your local machine from another terminal during the hang and reconnecting to the remote host? - Can you reproduce this behavior simply by unplugging your computer's ethernet cable for a period of time? If so, how long does it take (10 minutes? 30 seconds?)
- No, it doesn't get renumbered. I have also been able to reproduce similar behaviour just by blocking packets (DROP) on firewall... - That I am unsure, but I believe so. When I kill blocking sshd or shell that screen is attached to (from different connection and different box), screen moves from frozen state to normal state. - I don't understand this one. - Yes, firewalling out the connection on ssh client side does the same, so does unplugging of ethernet, so does cable modem loss. Approximately five minutes, but I think exact time depens on following: We've been looking into this with my friend and we think that this happens when something in the screen remains in SendQ, so your application running in the screen has to write anything to witness any effect. If nothing occurs on the terminal within the time window of approximately 10 or 15 minutes, ssh connection timeouts and applications within the screen remain unaffected and not blocked. Another friend found similar (i believe same) mis-behaviour with X server. We have host A and host B. Host B runs X server, while A is an X terminal. Host A boots up and creates session to B (A# X -query B). Then run xterm on A (which is in fact running on B, A is dumb terminal) and run screen on it. When ethernet link of A is uplugged, screen hangs within a while and that hang lasts few minutes, then screen changes into normal state (which I think is same behaviour I'm witnessing with ssh). I understand that this is not simple to reproduce or debug. If it was easy to debug, i would have done it myself.
Please see if: ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/screen-3.9.13-2.i386.rpm solves this.
Doesn't solve :-(
I would appreciate if you could try to reproduce with current release (4.0.2) in fedora core 3. Thanks.
After further investigation, the problem described happens like this: - screen client running in the hanging ssh session fills its buffers - the screen server will stop sending data to the client - screen server's buffers will fill - screen server will stop reading data from the client application - client application blocks in write (which is completely legitimate behavior) Thus, closing as NOTABUG.