Bug 75244 - screen freezes temporarily when remote connection to it is going to timeout
screen freezes temporarily when remote connection to it is going to timeout
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
7.3
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Petr Rockai
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-05 17:43 EDT by Jan Sembera
Modified: 2007-03-26 23:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-16 14:31:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Sembera 2002-10-05 17:43:20 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):


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:
Comment 1 Lon Hohberger 2002-10-08 16:01:41 EDT
Looking into this.
Comment 2 Lon Hohberger 2002-11-11 17:48:49 EST
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?)

Comment 3 Jan Sembera 2002-11-17 14:28:35 EST
- 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.
Comment 4 Lon Hohberger 2002-12-16 16:58:42 EST
Please see if:

ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/screen-3.9.13-2.i386.rpm

solves this.
Comment 5 Jan Sembera 2002-12-18 15:12:11 EST
Doesn't solve :-( 
Comment 6 Petr Rockai 2005-02-15 04:32:42 EST
I would appreciate if you could try to reproduce with current release (4.0.2)    
in fedora core 3. Thanks. 
Comment 7 Petr Rockai 2005-02-16 14:31:46 EST
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. 

Note You need to log in before you can comment on or make changes to this bug.