Red Hat Bugzilla – Bug 75244
screen freezes temporarily when remote connection to it is going to timeout
Last modified: 2007-03-26 23:57:29 EDT
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):
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 :-)
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
- 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
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:
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.