Gnu Screen ; an invaluable tool!

I wrote this Gnu Screen guide in December ’08 with the previous incarnation of in mind. January 2009 however, started on its new and exciting path as a community site and the article just sat on my machine, waiting. So I decided to publish it on my blog in a five part series over the following month. Maybe someone can use it 😉

Have you ever had to run a time consuming process (say mkfs or compiling something) over a shoddy ssh connection? Or cleanly run several commands in parallel without having several open connections to that server? Or maybe you were programming and wanted a mysql prompt, a bash prompt and several text editors open? How about that ssh tunnel you need open and dont want to close by accident? And did you ever need to perform the same task on several different machines? Or connect to a serial terminal? Or maybe you just want a log file of what you re doing..
These are day to day situations any linux user will run into, that can be quite frustrating. That is, before you discover Gnu screen!

“Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.” Or at least, thats what the site calls it. Sounds easy enough, but there are an amazing amount of different uses for this incredible piece of software. The above list is some of the uses I could readily think about – some of the ways I regularly use screen, but like any decent linux tool – the sky really is the limit! I’ll be looking into different issues, so lets jump into some of the practical solutions for those problems.

The Simple stuff
The simple way to use screen is to create a session, run a command in it, detatch the session and then, at some later time, reattach it again.

Creating a session is really simple.

 $ screen

Once the session is created, you ‘ll have a prompt where you can just run anything you need. Once you ‘ve started any program you d want to run, you can close the window you re running screen in or use the shortcut detach the screen session more elegantly. Each shortcut consists of a “Ctrl – a” followed by some other character.

C-a d
C-a C-d     (detach)      Detach screen from this terminal.

This is the notation used in the man pages. This combination detaches the screen session and leaves you on the terminal prompt where you started the session. The screen process continues in the background.
To take control of the session again, you can have screen reattach the running session.

 $ screen -R

This wil reattach the running screen session. There is a catch though, if there is more than one screen session active, this will not work. We will solve that in the slightly more advanced part.

Now lets take this dry manpage replication to the next level with some practical uses..

  • Have you ever had to run a time consuming process (say mkfs or compiling something) over a shoddy ssh connection?

This solution is quite straight forward. Open the connection to the remote server & open a screen session there. Run any commands you need inside the screen session. Now if the connection fails or if you accidentally close the window; screen will detatch and will still be running on the server. Next time you log on to the server, the screen process will still be there, working as you left it and waiting for you to reattach it. (providing noone killed it or did a reboot)

  • How about that ssh tunnel you need open and don’t want to close by accident?

About the same thing, with the difference that you ll want to create the screen session on your own machine. Open a screen session and start the ssh tunnel inside the screen session. Now you can close the term window or free up that terminal without closing your ssh connection & tunnel. You might consider scripting the process to open a gnome-terminal window with the new or reattached screen session. Next you could make life even simpler by adding the script to the desktop with a pretty icon. This is the trick I use to send mail over the internal office smtp servers. Thanks to this tunnel, I am sure I will always be able to mail out (providing ssh trafic is not being blocked..) even if the internal network wouldn’t normally allow it.

Slightly more advanced stuff
The slightly more advance stuff covers several screen sessions; naming your screen session; reattaching an attached screen session and more.. So lets dive in!

Lets say you’ve created a screen session, detatched it & created a second screen session. Now you have 2 screens running & the “-R” option wont choose for you which session to reattach. First we’ll need to check what screen sessions are running, using the “-ls” or “-list” option.

 $ screen -ls
There are screens on:
21251.pts-1.GenX	(Attached)
21229.pts-1.GenX	(Detached)
21211.pts-1.GenX	(Detached)

3 Sockets in /var/run/screen/S-gert.

In the above output, we can see my 2 detached screens & the one attached screen session. The command also shows the id, name and the server name in the following fashion “” Reattaching one of these is fairly simple.

 $ screen -r pid

To reattach a screen session, you use the pid of that screen session you want to reattach as a parameter. If you want you can use the full “” name, but this is not necessary. If you name your screen session you can also use the name to select the screen session you want to reattach. We ll talk about naming a session next.

When creating a screen session, the session gets a pid number and a name. When the user doesn’t choose a name, the system uses as standard name. You can name your screen session by adding “-S name” as a parameter.

 $ screen -S name

Now that we ve named our screen session, “-ls” gives the following output.

There is a screen on: 18665.Editor	(Detached)1 Socket in /var/run/screen/S-gert.

As you can see, the session is now named “” and can now be reattached with “screen -r Editor” as wel. The reason why to do this should be obvious as most people are better at remembering a chosen word instead of some random number.

Detaching and reattaching screen sessions creates the problem that a teminal may crash, leaving the screen session in an “attached” state, while for all practical purposes – its unattached. Trying to attach an attached screen session will trigger an error, telling you that there is no screen to be resumed and showing the session to be attached.

There is a screen on: 18665.Editor	(Attached)There is no screen to be resumed matching 18665.

To reattach that session, you will need to detach the session first. Detaching works exactly the same as attaching, using the “-d” option. Once the session is detached, you can reattach it again, as we described before.

screen -d Editor

The screen command is, as you might understand by now, quite extensive. Screen provides several options for this situation; combined lower and upper case “d” and “r” parameters for detaching or even forcing a session to be reattached. Anyone finding themselves in this situation should read the relevant man pages (“man screen”) to find the combination of parameters that best suits their specific needs. There is another option for dealing with an attached screen session and since its particularly interesting, we will go into more detail on that later.

These commands are all relative to the previous examples. Enabling you to enjoy different screen sessions and manipulate them with more ease. The logical next question here is what screen does in a multiuser environment. We all enjoy Linux’s strong user based approach and screen follows trough in this philosophy. Screen sessions belong to the user that started them and any user escalation that happens inside of the screen session (su, whatnot) remains within the session. Any security-conscientious user or administrator will make the obvious objections here (and should), but like other tools, screen is only as secure as the person using it.

The articles in this series were updated to; These articles focus on the following topics..

Published by Gert


3 thoughts on “Gnu Screen ; an invaluable tool!

  1. You may also want to consider a chapter on “voodoo”. 😉 Like sharing kerberos tokens or ssh agents between screens, or preserving/restoring them between attach/detach events.

    Only this week, I spent some quality time trying to modify the ssh-agent protocol to be a bit more screen-friendly (giving the client control over the socket created on the server instead of dumping it in /tmp), but there are some interesting edge-cases.

    I am very interested in hearing how others approach these issues.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: