bugGNU Screen - Bugs: bug #44243, Robust Session Restoration

 
 

bug #44243: Robust Session Restoration

Submitter:  Wyatt Epp <wyattepp>
Submitted:  Fri 13 Feb 2015 09:32:41 PM UTC
   
 
Category:  Feature Request Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  None
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 05 Sep 2015 02:14:31 PM UTC, comment #4: 

Yeah, it's impossible for screen to be responsible for state of applications, screen basically provides tty, and it doesn't care what runs inside, it only interprets some output.

Amadeusz Sławiński <amade>
Group administrator
Fri 20 Feb 2015 12:40:46 AM UTC, comment #3: 

The user manual at [0] is not up to date. Grab one from the newest source package. It'll be in screen-4.2.1/doc/screen.texinfo .

[0] https://www.gnu.org/software/screen/manual/

I wrote those descriptions and I'm fairly certain I did a poor job of it (suggestions are welcome). They do have to do with splits. A layout tracks how you organize your splits and restores them when you detach and re-attach GNUScreen or even start a fresh GNUScreen.

But I kinda agree with mikegerwitz's point of view. What may be confusing is the overloaded use of 'session'. A screen session will let you detach a shell from one terminal and reattach it to a different terminal. But if the underlying shell session dies because because of a reboot, that shell and its environment can't be recreated. For that kind of functionality, it sounds like you need something that will capture and act on a SIGTERM that gets sent on a shutdown. So when onSIGTERM() foreach (process) do { getCWD > ~/archeology_record.txt} or something along those lines.

You can do labeling inside GNUScreen. See the commands for :title , :windowlist , and :layout title. You can use :hardstatus for a persistant view of your windows. For dynamic titling, see [1]. Put all of this customization into your ~/.screenrc

[1] http://aperiodic.net/screen/title_examples

Your .screenrc can also help in automation. One example is at [2]. Take advantage of the (confusingly called) :screen command and :at command, and also look at the -X commandline option

[2] http://freecode.com/articles/the-antidesktop

HTH

Curtis Brown <mrbrown8>
Wed 18 Feb 2015 04:37:50 PM UTC, comment #2: 

That's vexing, but if it's the limit of what can be done I'd take what I can get-- saving windows and their titles would be substantially more than I already have.

layout dump sounds...close?  At least according to the random man page I found[0].  Confusingly, layouts don't appear to be documented in the screen manual[1] at all, so it's not clear what a layout is, exactly.  My impression is it's about window splits, which I don't actually use... I guess I'll try to build myself a recent-enough screen to test it later (a pox on Red Hat's packaging policies).

> saving the environment before each prompt


Interesting idea, though I'm really not sure how to scale it simply and transparently.

> And maybe give the sysadmins some advice on etiquette. :)


Believe me, I've tried. But company policy trumps common sense and "routine reboots" are a thing. :(

[0] http://man7.org/linux/man-pages/man1/screen.1.html
[1] https://www.gnu.org/software/screen/manual/

Wyatt Epp <wyattepp>
Sat 14 Feb 2015 02:08:41 AM UTC, comment #1: 

While GNU Screen would know the state of its windows, and the commands that were executed when they were opened (e.g. /bin/bash), it cannot be responsible for the state of those shells, or jobs running within them.  See the `layout dump` command in screen(1) for information on saving window layouts.

If you want to restore the state of the environment of a shell, record running jobs, etc, then you must do so from within the shell itself, perhaps by saving the environment before each prompt using `PROMPT_COMMAND` in bash.

And maybe give the sysadmins some advice on etiquette. :)

Mike Gerwitz <mikegerwitz>
Fri 13 Feb 2015 09:32:41 PM UTC, original submission:  

I'd like an option in Screen that associates a session with a file that's automatically kept up-to-date with the state of that session such that it can be recovered later, even if the machine it's running on is unplugged without warning.

Ideally this will preserve and restore windows, shells (with CWD), manually-set environment variables (i.e. via export), and whatever command was running in those shells (if they can't be automatically filled in/started, then I'd at least like to be able to find out what they were).

My rationale stems from my work, were the sysadmins will sometimes reboot my development server without warning me.  Currently, this means I lose my screens and whatever work I was doing at the time (usually three or four sessions with 6-9 windows each).  Making a bunch of windows only takes a little time, but losing the context of where I was and what I was doing tends to cost me at least half a day's work; more if it happens over the weekend (and still more if I ended the day deep in with gdb).

Wyatt Epp <wyattepp>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by mrbrown8 (Posted a comment)
  • -email is unavailable- added by mikegerwitz (Posted a comment)
  • -email is unavailable- added by wyattepp (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-05 amade StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code