Dealing with Disconnection.

by Chris Coleman chrisc@vmunix.com

I work at home from a dialup Internet connection. I have a small home network of about 4 computers of various types. All of them route through my BSD box to the Internet. Things work really well, except I live out in the middle of nowhere and the telephone lines here won't even let me connect at 28.8K. I think I get about 26.4K on a good day. Needless to say, it's slow.

I use ssh from my BSD desktop to connect to the computers I work on. They are all remotely hosted and I have never actually seen any of the boxes. Usually, I am editing files using vi(1), ytalk(1)ing to people, or reading my e-mail with pine(1).

My biggest problem working remote is not the lack of speed. I can deal with that - push a key, go eat lunch, no real problem. What I hate is getting disconnected. When I am in the middle of a project, the phone line goes dead and I lose all my work. vi(1) can sometimes be forgiving, and pine(1) is getting better, but it's far from the ideal method. I can usually recover part of my work.

Often after I get disconnected and log back in, the program I am working on is still running. Using w(1), I can see that the server still thinks that I am logged in and hasn't terminated the program. If only I could get control of that program again, I could keep working so I wouldn't lose any of my work.

I was ytalk(1)ing with a friend of mine the other day, and I got disconnected. Before I could rejoin the conversation, I had to kill my other ytalk(1) session and start over. When I explained that I had gotten disconnected, he asked me if I used screen(1). I immediately thought back to a utility that I had used when I first started using BSD. This utility would take a text console and split it in two, giving two windows with out using X. I never did get the hang of this program, and found my screen space shrinking in halves everytime I pressed the wrong button. I had abandoned it when I got X configured for the first time.

After some discussion, I realized that this was not what he was talking about. The program I was remembering was splitvt and not what I needed.

He ranted and raved about how wonderful screen(1) was and how the world needed to know about it. I told him I would look into it and if I liked it, I would write an article on it. Well, as you can tell, I liked it. It does exactly what I needed. Actually, it does quite a bit more than I needed.

The nice thing about screen(1) is that it gets out of your way. Once you run it, you can forget about it. It will be there when you get disconnected.

I found screen in the ports/packages collection under the misc section (/usr/ports/misc/screen) and installed it.

The install was simple and included a man(1) page, which I quickly read.

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells)

When I read the part about "full-screen window manager", I immediately thought of The X Window system and wondered if it somehow required X to be installed. As I read further, I realized that it was a window manager independent of X. It manages the current screen or window that you are using, allowing you to stack sessions on top of each other. Like cards on a stack, it allows you to flip through the active sessions you have open; viewing only one at a time.

This is very similar to the virtual console effect that BSD has when you are not using X. At the text console, pressing <ctrl> + <alt> + <f2> (or <alt> + <f2> on FreeBSD) will switch to another terminal where you can log in. In screen, you can press <ctrl> + <a> and then press 'n' to switch to the next screen session. But, unlike the virtual consoles where you have a set number of them, screen sessions don't exist until you start a new one.

Typing 'screen' at the command line will start your first screen session. Everytime you type 'screen' again, it will spawn a new screen session in the same window. For instance, I start screen and get a new command line back. Then I type screen again. It gives me another command line, exactly like the first, but the screen is clean. Pressing <ctrl> + <a> then 'n' will bring back the first screen session I was working on. (Hold down the ctrl key and press the 'a' key one time. Then press the 'n' key.)

Pressing <ctrl> + a and then '?' will bring up the help screen.

This lists all the key mappings. Each of the key mappings need to be proceeded by pressing <ctrl> + 'a', otherwise screen will pass it through as a shell command.

However, none of this is really what I was looking for. I was looking for a way to reconnect to programs that I had been disconnected from.

In the man page I found the syntax:
screen -r [[pid.]tty[.host]]

I assumed that the '-r' option was for recover.

I started screen on my remote workstation, loaded a program, and went for lunch.When I returned, I found that the screen was frozen and I had been disconnected. So I logged back in and checked the running processes. I noticed that I was still logged in on ttypc. So I typed

screen -r ttypc
There is a screen on:

79448.ttypc.vnode (Attached) There is no screen to be resumed matching ttypc.

hmm.. I thought. Maybe I need to type the whole thing. So I cut and pasted the screen name into the command.

screen -r 79448.ttypc.vnode
There is a screen on:

79448.ttypc.vnode (Attached) There is no screen to be resumed matching 79448.ttypc.vnode.

At this point, I got disconnected again. When I finally got reconnected, I thought I would try it without telling it which screen to get back. I had hoped it would give me a list of the screens running.

screen -r

Boom!. There was my session.

After a little playing around with screen, I realized that the screen session was attached to an active session, since the dialup connection hadn't closed it yet. When the attached shell died, I was able to grab the screen session and resume work. If I had wanted to detach the screen from wherever it was running and reattach it onto my new terminal, I could have used the detach command along with the reattach command:

screen -d -r 79448

If you use the 'w' command to see who is doing what, screen will show that you are logged into a screen session instead of a displaying where you are logged in from.

3:58PM  up 113 days, 21:23, 25 users, load averages: 1.06, 1.04, 1.04
USER             TTY      FROM              LOGIN@  IDLE WHAT
chrisc           pm       modem10-04:S.0    9:07AM     - w

The "modem10-04:S.0" listed above shows that I am dialed up from host 'modem10-04', using screen session 0. Normally, it would have appended the domain name from which I was connected. Instead, it appended the screen session name.

I have been using the same screen session for quite some time and really like how very easy it is to disconnect from and grab again when I come back.

-Chris Coleman chrisc@vmunix.com

[Editor's note: I am typing this note on a terminal inside a screen session that has been active since November 30, 1999; I simply detach and reattach the session whenever I switch workstations, and never have to close my work in progress. What a great tool! --gsutter]