Difference between revisions of "Shell Time-out"

From assela Pathirana
Jump to navigationJump to search
Line 74: Line 74:
{{Subscript|I learned this trick from: http://probability.ca/jeff/comp/routerfix.html (who wrote similar thing for C shell).}}
{{Subscript|I learned this trick from: http://probability.ca/jeff/comp/routerfix.html (who wrote similar thing for C shell).}}


#d <nowiki>
#d <pre>
</nowiki><pre>
PRE FORMATTED
PRE FORMATTED
</pre>
</pre>
#
#

Revision as of 15:09, 5 September 2006

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

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.

Fourtunately there are easy alternatives to this painstaking detective work.

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 singnals 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
  2. !/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)]

Acknowledgements

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

PRE FORMATTED