I am using GNU screen a lot. I find it very annoying that everytime the server has to be rebooted I lose all my sessions (even if I know in advance, I need to set-up everything again).

I've searched the web for possibilities how to make screen survive a reboot, but found nothing that works for me. Some of the methods I found and there flaws:

  • CryoPID: seems to be dead, promising since 2005 to include support for screen
  • DMCTP: has problems with setuid(), didn't work for me (I admit I didn't try very hard)
  • some script trying to recreate the session from scratch; you still lose your history and I think also the environments variables are not correctly set (and when I tried it didn't bring up all sessions)

Maybe somebody knows some better process freezer? This seems to be the most promising way.

  • Maybe you should hibernate instead of rebooting :-) I remember using DMCTP a long, long time ago and it worked (IIRC, but i'm not sure...)
    – sloth
    Sep 28, 2010 at 8:39
  • 1
    Well, in most cases its kernel updates or hardware replacements that force a reboot. (Which is not up to me anyway...) -- DMCTP: Would be interested in how to make it work without recompiling screen (as suggested on the Internet). Sep 29, 2010 at 10:31
  • 1
    I'm using tmux instead of screen and find it easier to write session scripts. That doesn't "save" your session but you can easily send commands to tmux to do your layout and send 'key strokes' to the client so you can change directory and launch applications if needed. I'm sure you can do it in screen as well, but it's just seem easier with tmux
    – mb14
    Sep 30, 2010 at 9:18

3 Answers 3


There is no way to save a screen session in the fashion that you desire. What I did was the next best thing: scripted autossh to connect to my servers and set up my rig the way I like it.

Love it.

Local connection down, I wait, it comes back up and there's my work ( I use nested screens ). Server down or rebooted, I wait, and am back in my default position. This gives me the feeling of continuity that I desired.

Anyway, I asked this exact question years ago on the screen list.

Summary: Seek not eternal life for screen. Instead learn to resurrect.

This is the meat of the .screenrc config:

There is an example, rscreen, in the autossh package that I modified into the econnect program.

The --esc parameter is to set the remote screen escape to something different ( my escape is `)

#add much much more scrollback
defscrollback 10000

# make some default windows

screen -t ADMIN     1
chdir /Users/chiggsy/Sites/
screen -t SITES    2
chdir /Users/chiggsy/src/
screen -t SRC 3
screen -t FERGUS  4 /Users/chiggsy/bin/econnect --host host.example.com --port 50000 --esc g --user sol
screen -t LAEG 5  /Users/chiggsy/bin/econnect --host host.example2.com --port 505000  --esc g --user invictus

screen -t ROOT      0   sudo su -m

See: http://skoneka.github.io/screen-session/

Available screen-session modes: 

save              - save Screen ( and VIM ) session 
load              - load session 
ls                - list saved sessions 

dump              - print detailed informations about windows in the session 
group             - move windows to a group 
layoutlist        - display a list of layouts 
layout-checkpoint - record a snapshot of the current layout. 
layout-history    - display saved snapshots of the current layout 
layout-redo       - load a snapshot of the current layout, 
layout-undo       - load a snapshot of the current layout, 
layout-zoom       - zoom into and out of a region 
kill              - send SIGTERM to last the process started in a window 
kill-zombie       - kill all zombie windows in the session 
kill-group        - recursively kill all windows in a group 
manager           - sessions manager (screenie like) but featuring session 
                    preview in a split window 
nest-layout       - copy a layout to the current region 
new-window        - start a new Screen window in the same working directory 
                    on the position next to the current window 
name              - get or set the sessionname 
regions           - display a number in every region (like tmux display-panes) 
renumber          - renumber windows to fill gaps 
subwindows        - recursively print windows contained in groups 

On Server Fault, the same question has received one hint which is missing here: use tmux with tmux-resurrect, which is:

Restore[s] tmux environment after system restart.

What it can restore for you:

  • all sessions, windows, panes and their order
  • current working directory for each pane
  • exact pane layouts within windows (even when zoomed)
  • active and alternative session
  • active and alternative window for each session
  • windows with focus
  • active pane for each window
  • "grouped sessions" (useful feature when using tmux with multiple monitors)
  • programs running within a pane! More details in the restoring programs doc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .