Author: Brian Jones
lives as easy as possible, we sometimes find ourselves learning about such
obtuse things as advanced regular expressions, SNMP, rstatd, or the intricacies
of RAID. For this reason, we breathe a collective sigh of relief when we find
a simple, flexible tool readily available to help us out. One oldie-but-goodie
that I find goes unnoticed and/or underutilized all too often is ‘screen’.
If you read the first line of the screen man page, it says that screen is,
well, a ‘screen manager’. If you read on, you’ll be overwhelmed by the number
of options available to you. There are options for starting screen, options for
managing screens, and options available from within a screen session. In this
article, I’ll give you a quick sampling of screen’s useful features through a
couple of small vignettes that I call, collectively, “The Beauty of Screen”.
Scenario 1: Don’t Close That Session!
It’s 4:45pm. You have a
kernel configuration all ready to go, and you really want to get through the
long, boring “make” process so that you can start tomorrow morning off with a
fresh kernel, ready to be installed and tested. Hardly seems worth kicking this
off now – it’ll take at least 10 minutes to run, and that’s if everything goes
flawlessly.
You can’t stay late tonight. You gotta get outta there right at 5 – what do you
do? Screen to the rescue!
Here’s the deal: If you have a normal old shell session, just type
‘screen’. The current shell session will clear and present you with a fresh
new shell session. Now, in the new session, browse to your kernel source
directory, and start your make process (“make bzImage;make modules;make
modules_install” for example), and as soon as you feel things have kicked off
without issues, type the magic keys: “Ctrl-A” (to get screen’s “Attention”),
followed by “d” – for “detach”. This will dump you back into the shell
that launched the screen session. Log out. Go home.
Yes, I said log out. The beauty is that now you are free to get out of your
cube right at 5, and the screen session continues to run. After happy hour,
when you get home, you can ssh back into the box at work (‘cos we don’t use
telnet, right?), and run “screen -r”. Assuming you only have a single screen
session running, this will reattach you to your kernel building session already
in progress. If anything went wrong, you can correct any mistakes, type “Ctrl-A
Ctrl-D” again, and call it a night. Your session will be waiting for you to
reattach to when you get back to your desk.
Scenario 2: “Flash Remoting”, Linux Admin Style
You manage a long list of machines from your main desktop. You’ve played with a
host of proposed solutions to the problem of automating your desktop login routine to
include opening sessions to at least some subset of these hosts. While some of
these solutions are actually pretty decent, there’s one I’d like to show you
that will exhibit more of screen’s power and flexibility, and might just become
your favorite way of automating this process.
This process makes one, arguably broad, assumption. It assumes that you use SSH
keys rather than typing a password for every host you log into. If that’s true
for you, then you can just create an initialization script with lines for
each host you want to open a session for. Here’s the lines from my own init
script:
#!/bin/bash
screen -d -m -S svr1 -t jonesy@svr1 ssh server1.linuxlaboratory.org
screen -d -m -S svr2 -t jonesy@svr2 ssh server2.linuxlaboratory.org
screen -d -m -S svr3 -t jonesy@svr3 ssh server3.linuxlaboratory.org
You can call this script at will from the command line to open all three
sessions. I don’t recommend putting this in a shell initialization script,
however, since it would be very easy to create an endless loop of ssh sessions
in environments where home directories (and therefore, shell init scripts) are
shared across hosts. It might be safer to put them in an xinitrc file. Since
the “-d -m” flags together cause the screen sessions to fork new processes,
logging out of X won’t destroy your screen sessions.
This brings up an important point: screen sessions have nothing at all to
do with an open window in a terminal application like Konsole or xterm. Each
one is an entity unto itself, independent of any other processes you might be
running. Now – on with the show.
After the above lines run, assuming all of the logins are actually successful,
you should be able to open a terminal and type “screen -list”, and get output
similar to this:
[jonesy@livid jonesy]$ screen -list
There are screens on:
5372.svr1 (Detached)
5375.svr2 (Detached)
5378.svr3 (Detached)
4 Sockets in /home/jonesy/.screen.
Your screen sessions are listed using the format
process-id.session-name status. Note that the session name was made a bit
friendlier by the addition of the “-S” flag to the screen commands in our init
script. The reason I do this is because you can refer to the sessions using the
value of
“screen -r svr1”, and I’m there. Without the “-S” flag, however, I’d be forced
to remember the process ID of each session, and which host each PID is
associated with. Then I’d type “screen -r
wanted. That would be suboptimal.
So now you have a terminal open, you typed “screen -r svr1”, and you’re on
your host of choice. Well – whose desktop is that simple? In reality, you have
5 terminals open, and you may or may not have a system for organizing them. You
need to connect to any screen session from any random terminal window on your
desktop (or any virtual terminal on your system!). Furthermore, you don’t wanna
pay attention to detaching a session in one window before you connect in
another – you want total session ubiquity – and you get that with screen!
So you have 5 windows open, and in window 1, you have a session open to “svr1”.
Something draws your attention elsewhere, and you start working in
window 5. Fifteen minutes later, you’ve checked email, ran for coffee, come
back, and started working in one of your hodgepodge of terminal windows. You
need to get on svr1 again, but don’t feel like cycling through all your windows
to find it – no problem. Just type “screen -D -R svr1”. You’re in control. The
“-D -R” options to screen tell it to attach to svr1, detaching the “lost
window” from the session first. Not bad!
In Closing
I’ve only touched on those features of screen that I use on a daily basis. It’s
only a small subset of screen’s true power. With some reading and practice, you
can do amazing things with screen. Using nested screen sessions, for example, you can create
more complex working environments that make administration of machines at
various remote sites a breeze to organize and take control of. Running screen
SUID root enables you to allow multiple users to connect to a single screen
session.
There’s no end to what screen can do. I hope this article inspires you to start
grokking ‘screen’.
