bugGNU Screen - Bugs: bug #24302, inconsistent output in detached...

 
 

bug #24302: inconsistent output in detached screen sessions

Submitted by:  None
Submitted on:  Fri 19 Sep 2008 02:14:13 AM UTC  
 
Category: Program LogicSeverity: 3 - Normal
Priority: 5 - NormalStatus: Need Investigation
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: 4.0.3
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.

 

Fri 19 Sep 2008 02:14:13 AM UTC, original submission:

I'm getting some odd behaviour when i use:

echo "yum -y update" > ./tmp ; screen -d -m bash --rcfile ./tmp ; rm -f ./tmp

the reason i want to run this is:
1) i want to start an update process automatically (using at) so that no-one needs to be on site for the commencement of an outage, but the attending sysadmin can still look over the overall output to verify the operation succeeded/failed.

2) I would prefer this over looking at /var/log/yum.log because if the attending sysadmin arrives s/he can step into the session and observe progress.

3) Any odd errors should be captured in context, and are not limited to yum

why invoke the command like this:
1) screen -d -m <cmd> means that the screen will start with <cmd> running inside of it, and then detatch.
<cmd> here is bash --rcfile <some file> where <some file> is pre-loaded via an echo, but can of course be created via an editor.

2) importance of <cmd> being bash --rcfile, rather than `yum -y update` or anything else for that matter short of a shell. bash without --rcfile terminates after completion, with bash is started to execute the instructions in rcfile specified.

The actual fault:
Sorry about the long road here, the problem is that screen is not consistent in how it operates:

occasionally i run it and then connect to it using `screen -r` or run `screen -ls` and connect to the listed session using `screen -r -d <session id>` and there will be what yum has been doing. But quite often there will be a shiny new, and apparently untouched, prompt.

Log files can verify that the yum did actually run and complete, however the output is not visible, but sometimes it is.

There seems to be a consistent thread however: it appears to relate somehow to the activity of the command. For example, if instead `yum -y update` something like `while true; do echo it works; done` connecting to the screen succeeds with the output being visible.

Issue 1:
consistency - this might not be a bug and i might just type faster some times and not other times. However i have used `echo "hello"` in my rcfile and observed it. So i have some doubts there, however in writing this, was unable to replicate this.

Issue 2:
maybe i'm doing something i shouldn't - i'm relatively new to screen, i've been using it to work around a firewall bug, and really only to start, work in it, and reconnect if need be. I seldomly disconnect and rejoin. Recently i found the ability to work cooperatively using it, but this is probably the fanciest i've attempted to do. Am i maybe just missing something in the man page?

Urgency / Impact:
Minute - neither cron nor at let me actually see a session that screen should have created anyway, so even if this were to be sorted out, odds are it would not fix >my< problem. but it might make screen more consistent.

Cheers, and sorry if i gave too much information / detail.

-unavailable-

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 (Updated the item)
  •  

    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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 15 Jan 2009 10:52:26 PM UTCmicahcowanStatusNone=>Need Investigation
      Planned ReleaseNone=>Later

    Back to the top


    Powered by Savane 3.1-cleanup1