Shell Time-out

From assela Pathirana
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
DSC 0102.JPG

It is a simple, but annoying problem. You login to a remote server using ssh and start working on a long program, start editing away and the phone rings, you leave the computer only to find that it is uncle bob, who has this nasty habit of never letting the phone go! When you return to the computer after 38 minutes, your login window has frozen!! As a result all the editing work has been lost!!!

What happens

Check around in the web and we see a lot of variation in the explanations given to this behavior. In fact it can be any bottle-neck down the line from your computer (client) to the server that is closing the connection automatically after some time of inactivity. There are various solutions for each of these, but I believe it is not worthwhile to spend time on figuring out each of these in many practical situations. For example, in order to access a Linux server in the outside world from my PC at office [23:27, 5 September 2006 (JST)] outside world I have to hop through no less than three servers due to various 'security measures' -- good luck if someone wants to find out which part is causing the trouble.

Fortunately there are easy alternatives to this painstaking detective work.

The Lazy solution

Scenario

Usually I login by ssh with X11 Forwarding:

ssh -X myname@server

or

ssh -Y myname@server

This allows me to run graphical ([[X) applications on the server, displaying the results in my client machine. This requires

  1. A X server Cygwin/X like running on my client machine.
  2. The server I am connecting to allows X11 Forwarding in its ssh configuration.

Solution

Rather simple. Start an application that regularly requires sending signals back/forth, but with less demands on resources (CPC, memory, bandwidth). The best candidate is perhaps,

xclock &

Then, simply your server will keep on sending signals required to display time on the clock shown on your client machine and Uncle Bob can talk whole day, but your connection will be safe!

Difficult/ elegant/ geeky/ fill-in-the-blank solution

Here let's assume our login shell is bash. Of course one can modify the following for any other shell.

  1. Add the following to the .bash_profile file (in ~/.bash_profile):
if [[ -n $TERM ]]; then
   if [[ -n $SSH_CLIENT ]]; then
      ~/bin/sendnulls &
      export SENDNULLS_PID=$!
      echo "$SSH_IP: sendnulls started (pid $SENDNULLS_PID)"
   fi
fi
  1. Then save the following code as ~/bin/sendnulls
#!/bin/bash

while true
do
  dd if=/dev/zero count=1 bs=1 2>/dev/null
  sleep 60
done
  1. finally add the following to ~/.bash_logout file.
if [[ -n $SENDNULLS_PID ]]; then
     echo "killing sendnull (pid $SENDNULLS_PID)"
   kill $SENDNULLS_PID
fi

That's it!

What this does

  • When we log in
    1. It starts the sendnulls program in background
      • which sends a null_character once every minute from server to client. Since it is a null character we don't see it, so no harm done. But, everybody along the long line from the server to the client is woken up!
    2. Creates a shell variable named SENDNULLS_PID storing the PID of the process running the sendnulls program.
  • When we log out it simply stop the sendnulls program by killing the PID represented by
    1. Simply kill the sendnulls program, i.e. kill the PID in SENDNULLS_PID.
[18:27, 3 September 2006 (JST)]

Acknowledgments

I learned this trick from: http://probability.ca/jeff/comp/routerfix.html (who wrote similar thing for C shell).