bugGNU Screen - Bugs: bug #25767, Locks up if remote system...

 
 

bug #25767: Locks up if remote system hibernated/suspended

Submitted by:  None
Submitted on:  Thu 05 Mar 2009 08:54:59 AM UTC  
 
Category: Crash/Freeze/InfloopSeverity: 3 - Normal
Priority: 1 - LaterStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: ClosedRelease: 4.0.2
Fixed Release: NonePlanned Release: Later
Work Required: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 10 Mar 2009 05:03:06 AM UTC, comment #5:

If that option helped, then with your permission, I'll close this bug out.

I am as puzzled as you as to why the default is not to set a reasonable timeout for response from a display. I've sent the query to the list, and if no reason is given, I'll ask that we change this policy. :)

http://lists.gnu.org/archive/html/screen-devel/2009-03/msg00000.html

If you desire, a new bug may be opened to address this separate issue.

Micah Cowan <micahcowan>
Mon 09 Mar 2009 04:03:34 PM UTC, comment #4:

The 'defnonblock 1' option may have helped.

I wonder why this is not the default? It's how a "screen" should behave, instead of locking up, which I see as a serious bug.

Anonymous
Sun 08 Mar 2009 07:15:25 AM UTC, comment #3:

Hm. Perhaps try that option with a newer version of screen then, I cannot reproduce your situation so long as I use that option in the display that abruptly loses its connection, in 4.0.3.

Micah Cowan <micahcowan>
Sat 07 Mar 2009 03:26:50 PM UTC, comment #2:

This option is of no help. Still locks up. And to clarify: killing the offending window locks up the entire screen.

Anonymous
Fri 06 Mar 2009 07:10:46 AM UTC, comment #1:

Try adding "nonblock 1" to your ~/.screenrc

In the case of existing displays that are not set to "nonblock" mode and are already hung, try:

C-a : at % nonblock 1

(Feel free to reopen this bug if this advice did not help you)

Micah Cowan <micahcowan>
Thu 05 Mar 2009 08:54:59 AM UTC, original submission:

If a computer with screen attached in an ssh session is hibernated or suspended (Windows, putty), subsequently attaching the screen via another computer causes it to lock up. Sometimes only one window, and it may still recover from it. But usually this gradually extends to all windows being locked up, and it being impossible to even attach from another ssh session. The only thing that causes any response from screen is kill -9.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by micahcowan (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 10 Mar 2009 05:03:05 AM UTCmicahcowanStatusNeed Info=>Invalid
      Open/ClosedOpen=>Closed
    Sun 08 Mar 2009 07:16:25 AM UTCmicahcowanPriority5 - Normal=>1 - Later
      StatusInvalid=>Need Info
      Open/ClosedClosed=>Open
      Planned ReleaseNone=>Later
    Fri 06 Mar 2009 07:10:46 AM UTCmicahcowanStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1