Dealing with Disconnection

I sometimes work at home from a VPN Internet connection. I also have a small home network of about 4 computers of various types. All of them route through my BSD box to the Internet. However, like most people I travel back and forth to the office each day. Sometimes, when I'm working, I don't want to stop what I'm working on remotely just because its time to leave.

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), managing asterisk servers from the console or setting up opensips processes.

My biggest problem working remote is not the lack of speed, highspeed internet really solved that, not like in the old days when I first started doing this. I remember dealing with that - push a key, go eat lunch, no real problem. But when working remote, the biggest problem is getting disconnected. Its really frustrating when I am in the middle of a project and the VPN gets disconnected or the WiFi just loses signal because someone turns on the microwave and I lose all my work.  vi(1) can sometimes be forgiving, but it's far from the ideal method. I can usually recover part of my work.

Back when dialup was the only option, I would often get disconnected and log back in and the program I was working on was still running. Using w(1), I could see that the server still thought that I was logged in and hadn't terminated the program.

I was still working from dialup back when a friend of mine introduced me to screen(1). He ranted and raved about how wonderful screen(1) was and how the world needed to know about it. I've been using it ever since.

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 closed the remote window and then 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.headroom (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.headroom
There is a screen on:

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

After a little playing around with screen, I realized that the screen session was attached to an active session, since the  connection hadn't closed it yet. When the attached shell dies, I am 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 -rd

Boom!. There was my session.

I also could have done:

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
maxh           pm       maxh10-04:S.0    9:07AM     - w

The "maxh10-04:S.0" listed above shows that I am connected from host 'maxh10-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.