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:
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:
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 <session-name>. So, to attach to the session on "svr1", I just type "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 <pid>" to connect to the host I 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 ClosingI'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'.