One of the things I find rewarding about administering Linux and Unix systems is that there are so many tools out there to help you get your job done. For almost every conceivable class of problem out there, someone has taken the time to craft a utility to address it. And every now and then, that utility is ingenious enough to entirely change how you look at the problem. To me, screen is just such a utility.
Perhaps I'm so impressed by screen because I didn't know of its existence for the first 10 years or so that I worked with Unix systems. I wasted a lot of time trying to work around the class of problem it solves. Or, perhaps I'm just easily impressed. But if screen is new to you, or if you know it and would like some tips on using it, read on.
The screen utility is a terminal multiplexor; in essence this means that you can use a single terminal window to run multiple terminal applications. You might be thinking, "Big deal, I can do that now by putting the job in the background on the shell." Sure you can, but what about programs that don't lend themselves to being backgrounded -- say, something written in ncurses? Or, what if you need to exit your terminal session entirely? And what if, for either or both of the prior conditions, you might want to interact with that program at some later date?
Screen will allow you do all of these things. Your program will be blissfully unaware that you're not right there, babysitting it. There is no client or server piece as with some "remote" tools; as long as screen is installed on the system where you want to run your job and you can connect to that system, you have everything you need. Another benefit of screen is that it is written and maintained by GNU and, therefore, is available on almost any Unix platform imaginable. (For anyone who administers multiple flavors of systems, this is key because it means that you can rely on the same tool across multiple platforms.)
Examples of screen at work
I operate a low-power FM transmitter in my home to broadcast my music collection. (The transmitter is less expensive than running wires and lets me carry a Walkman around in the yard and still hear my tunes.) I drive the transmitter with mp3blaster, which is a nice console-based MP3 player with support for large MP3 collections. Once it's running, mp3blaster might look like this:
So far, so good: I can open a window, kick off mp3blaster and have music for days. But what if I'm sitting upstairs on my laptop and don't want to have run downstairs to change play lists? Simple, I start mp3blaster under a screen session and then can access it from any system that has shell access to the system where the screen was invoked.
I could start a screen session called "radiostation" in this way:
[email protected]:~$ screen -S radiostation
[email protected]:~$ mp3blaster (load my playlist and hit play to start transmitting)
(hit 'Control-a' followed by 'd' to detach)
At this point, I can exit my shell, and mp3blaster keeps on running, happily updating the (now non-existent) terminal window with current track information and elapsed time. Let's say that my wife calls me at work and says, "Hey, make this thing play something other than your music." Then, I ssh into ghostrider and resume my session with:
[email protected]:~$ screen -r radiostation
If I happen to forget the name of the screen sessions I have running, I can use the "-ls" switch to see what's available:
[email protected]:~$ screen –ls
There are screens on:
2 Sockets in /var/run/screen/S-tmancill.
If I leave the office without logging out of that "radiostation" screen, I can still resume it by instructing screen to detach (-d) any running session before resuming (-r) the session I'm requesting. In my window at the office, I'll see:
[email protected]:~$ screen -r radiostation
Of course, you don't have to be running a radio station to get some use out of screen. It's very useful in a production environment where you don't know from what location you might be needed to access a session. At my office, we needed to run a piece of vendor software underneath GDB in order to be able to produce backtrace information when it segfaulted. When the segfault occurred, our monitoring software would alert us and the on-call member of our support team would produce the backtrace and restart the software. Since any of a number of folks may need to access the session, running the GDB shell on any of our individual workstations was out of the question. One option would have been to run the software directly from the system console, but this meant that the on-call tech had to be onsite and go physically into the data center to perform the reset. So, screen was a natural fit.
Be cautious about one thing: Screen is sensitive to user permissions, and to users in general. In the GDB example, the vendor software ran under a specific user account, so if you used "su" or "sudo" became another user, you could expect permissions problems. Part of this is that screen needs to be able to open your tty. For example, let's say that I want to run something as the user "asterisk" under screen on my system. If I login in the user "tony" and then become the user "asterisk," I'll run into the following:
[email protected]:~$ screen -S pbx
Cannot open your terminal '/dev/pts/146' - please check.
[email protected]:~$ ls -al /dev/pts/146
crw------- 1 tony tty 136, 146 May 31 18:16 /dev/pts/146
As you can see, for the sake of security, my tty is owned by the user who opened the shell, not the effective user ID after I became asterisk. One way around this is to log in directly as the user asterisk before invoking screen. This problem can present itself on the other side as well. That is, if I start the job as asterisk, and log in to a box under another username, and then become asterisk, "screen -r" will still be unable to open the terminal. Also note that before I become the user asterisk, "screen -ls" won't even show me that "pbx" session; appropriately, screen creates a directory for each screen user, and only lists that user's sessions.
How do you get around the permissions problem? If the user account has a password, you can always ssh into the system (probably localhost) directly as that user. Or, if you're in a huge hurry and feel confident that there isn't a local security threat, you can change the permissions on the tty. If you do this, be sure to log out of your terminal as soon as you're done. In effect, you're giving every local system user access to that login shell. Another option is to become root and invoke screen, and then become the system account needed to run the job within the screen session. This will work because the superuser is able to open any user's tty, and (ostensibly) your support staff has sufficient rights to become the root user.
So screen can help you use a large family of terminal software that may not be suited for "unattended" use and yet must be accessible to more than just your initial login session. It's so quick and easy to use that you might prefer it over multiple logins into a remote system, or even over setting up additional virtual consoles on your Linux console. And that's it -- the cereal box guide on a tool that will let you be there when you're not, and still get there when you need to.