2004-11-30, 12:30 AM
Screen is a console based session manager capable of supporting many virtual sessions inside the same console session. It also has the ability to maintain a session that you have disconnected from and allow you to return to that session later.
I started using Screen when I became a heavy user of IRC. Because I switch between my Linux computer and my Windows computer, I was not able to standardize on one IRC client and use it in both environments. My IRC client of choice is Irssi (a console based client with many features) and it is only available in the unix environment. I made the decision to run my Irssi client from my remote shell inside a Screen session. This allows me to connect to my IRC client regardless of the machine that I'm currently on, reattach to my Screen session to regain control of my client.
But, Screen has many other uses besides IRC. For instance, I can remotely manage all of my servers using Screen. I am also able to start my upgrades/compiles inside a Screen session, disconnect, and return later to see how the job is progressing. Even involuntary disconnects are no problem because Screen sees the disconnect and waits for me to reconnect to the session.
For a simple example, run "screen" at the command line. Assuming you have the package installed on your machine, you will immediately be returned to a prompt. Start something running, perhaps your e-mail client, and then issue the command "Ctrl-a d". That is, Control a and then hit d. Ctrl-a is the default Screen alert key and the "d" tells Screen to detach from the process. You should now be back to the console without your email program. However, your e-mail program is still running, it is just running in a detached Screen session. To show this, type "screen -ls" at the prompt. Screen will reply with the sessions that are currently running. Assuming you have been following directions and you do not have but one Screen session in the background, you can simply type "screen -r" at the prompt and Screen will reattach the detached session and return you to your email client.
With multiple sessions in the background, the output would look something like this:
$ screen -ls
There are screens on:
21561.pts-0.ur2 (Detached)
21578.pts-0.ur2 (Detached)
2850.pts-0.ur2 (Detached)
3 Sockets in /var/run/screen/S-me.
The session I am writing on is "2850.pts-0.ur2 (Detached)" and assuming I want to return to the session and continue to write this document, I type
$ screen -r 2850
and it puts me back here.
The other sessions continue to run detached, however. I can go to another console to attach to them or I could connect in via the network and grab them from there.
Some other tricks that are available and are covered in the excellent man pages for Screen are:
- You have the ability to run multiple virtual terminals from within one Screen session and switch between them with "Ctrl-a n". The session I am currently using has this terminal where I am editing this document in vi, a second terminal where I am compiling some software, and a third where I am running a tail on my syslog files to watch my apache web server.
- The ability to have multiple attaches to the same session. Imagine a party line where everyone can see and type to the same console screen. If, from another console I ran screen -x 2850, I would see me typing this document from my earlier session. Both sessions have keyboard and screen control, so input can come from either or both at the same time.
- You can password protect Screen sessions when you want to add another layer of security on top of normal *nix security. - Screen has the ability to log everything that occurs during a session so you can review it later. For example, if you are compiling your kernel in a Screen session, you could start logging, start the compile, detach from the session and return to it later to see if your kernel compiled the way you wanted. You could then review the logs and check for errors.
- Screen maintains a scrollback buffer that you can scroll back through if you wish. You have the ability to configure the size of the buffer in your ~/.screenrc file.
- Using the "-S" option, you can name your sessions to make them easier to tell apart when you have several to sort through.
- Using the "-X" option, you can send commands to running Screen sessions without attaching to them first.
I have discovered over the years of running my servers that there are times that I need to restart certain services such as sshd or networking in order to re-read config files or pick up new settings. Have you ever tried to restart networking remotely? You will find that as soon as networking goes down, the session drops and any processes that were attached to the session also die. In this case, the 2nd half of the network restart dies before it can ever run. However, using Screen to protect the session from disconnecting, I can safely restart networking (/etc/init.d/network restart) from within the Screen session and the session does not die when the network goes down. In fact, I can't remember a time when, while using Screen to do this that I even lost my remote connection to the server. The service stops and restarts just as if I was sitting at the console.
Screen is one of those programs that the more you use it, the more you see opportunities to use it. I have and will continue to recommend all users be familiar with it's capabilities.
P38
Thanks to |Sanchez| in #linux-noob (EFnet) for his help in proofreading this document.
The following is a .screenrc from one of my machines.
$ cat .screenrc
# the hardstatus line appears at the bottom of my screen on every screen session
hardstatus on
# the following formats the hardstatus line to remind me of the alert
# key for the server I am on, the name of the server and the string
# of characters that follow shows the open sessions on the status line
# in a format similar to tabs.
hardstatus lastline "[CTRL-A] RECORDER: %-Lw%{= bw}%50>%n%f* %t%{-}%+Lw%<"
# i prefer to hear the bell instead of flashing the screen.
vbell off