Difference between revisions of "Shell Time-out"

From assela Pathirana
Jump to navigationJump to search
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
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.
[[Image:DSC 0102.JPG|thumb|right|200px]]__TOC__
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==
==What happens==
[http://www.google.com/search?hl=en&q=ssh+timeout 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.  
[http://www.google.com/search?hl=en&q=ssh+timeout 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.  
Fortunately there are easy alternatives to this painstaking detective work.


==Lazy solution==
==The Lazy solution==
===Scenario===
===Scenario===
Usually I login by ssh with [[wikipedia:Cygwin/X#X11_Forwarding|X11 Forwarding]]:  
Usually I login by ssh with [[wikipedia:Cygwin/X#X11_Forwarding|X11 Forwarding]]:
<nowiki>
<nowiki>
  </nowiki><pre><nowiki>
  </nowiki><pre><nowiki>
ssh -X myname@server
ssh -X myname@server
</nowiki></pre>  
</nowiki></pre>
or  
or
<nowiki>
<nowiki>
  </nowiki><pre><nowiki>
  </nowiki><pre><nowiki>
ssh -Y myname@server
ssh -Y myname@server
</nowiki></pre>
</nowiki></pre>
This allows me to run graphical ([[[[wikipedia:X|X]]) applications on the server, displaying the results in my client machine. This requires  
This allows me to run graphical ([[[[wikipedia:X|X]]) applications on the server, displaying the results in my client machine. This requires
# A X server [[wikipedia:Cygwin/X|Cygwin/X]] like running on my client machine.  
# A X server [[wikipedia:Cygwin/X|Cygwin/X]] like running on my client machine.
# The server I am connecting to allows X11 Forwarding in its ssh configuration.  
# The server I am connecting to allows X11 Forwarding in its ssh configuration.


===Solution===
===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,  
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,
<nowiki>
<nowiki>
  </nowiki><pre><nowiki>
  </nowiki><pre><nowiki>
xclock &
xclock &
</nowiki></pre>
</nowiki></pre>
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!  
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==
==Difficult/ elegant/ geeky/ fill-in-the-blank solution==
Here let's assume our login shell is [[wikipedia:bash|bash]]. Of course one can modify the following for any other shell.  
Here let's assume our login shell is [[wikipedia:bash|bash]]. Of course one can modify the following for any other shell.
# Add the following to the <tt>.bash_profile</tt> file (in <tt>~/.bash_profile</tt>):  
# Add the following to the <tt>.bash_profile</tt> file (in <tt>~/.bash_profile</tt>): <nowiki>
<nowiki>
</nowiki>
</nowiki><pre><nowiki>
<pre><nowiki>
if [[ -n $TERM ]]; then
if [[ -n $TERM ]]; then
   if [[ -n $SSH_CLIENT ]]; then
   if [[ -n $SSH_CLIENT ]]; then
Line 43: Line 44:
fi
fi
</nowiki></pre>
</nowiki></pre>
#Then save the following code as <tt>~/bin/sendnulls</tt>  
#Then save the following code as <tt>~/bin/sendnulls</tt> <nowiki>
<nowiki>
  </nowiki>
  </nowiki><pre><nowiki>
<pre><nowiki>
#!/bin/bash
#!/bin/bash


Line 54: Line 55:
done
done
</nowiki></pre>
</nowiki></pre>
#finally add the following to ~/.bash_logout file.  
#finally add the following to ~/.bash_logout file. <nowiki>
<nowiki>
  </nowiki>
  </nowiki><pre><nowiki>
<pre><nowiki>
if [[ -n $SENDNULLS_PID ]]; then
if [[ -n $SENDNULLS_PID ]]; then
     echo "killing sendnull (pid $SENDNULLS_PID)"
     echo "killing sendnull (pid $SENDNULLS_PID)"
Line 66: Line 67:


==What this does==
==What this does==
* When we log in  
* When we log in
*# It starts the <tt>sendnulls</tt> program in background
*# It starts the <tt>sendnulls</tt> program in background
*#* which sends a [[wikipedia:null_character|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!  
*#* which sends a [[wikipedia:null_character|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!
*# Creates a shell variable named <tt>SENDNULLS_PID</tt> storing the [[wikipedia:Process_identifier|PID]] of the process running the <tt>sendnulls</tt> program.  
*# Creates a shell variable named <tt>SENDNULLS_PID</tt> storing the [[wikipedia:Process_identifier|PID]] of the process running the <tt>sendnulls</tt> program.
* When we log out it simply stop the <tt>sendnulls</tt> program by killing the PID represented by  
* When we log out it simply stop the <tt>sendnulls</tt> program by killing the PID represented by
*# Simply kill the <tt>sendnulls</tt> program, i.e. kill the PID in <tt>SENDNULLS_PID</tt>.  
*# Simply kill the <tt>sendnulls</tt> program, i.e. kill the PID in <tt>SENDNULLS_PID</tt>.
{{Subscript|[18:27, 3 September 2006 (JST)]}}
{{Subscript|[18:27, 3 September 2006 (JST)]}}
----
----
=={{Subscript|Acknowledgements}}==
=={{Subscript|Acknowledgments}}==
{{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).}}
[[Category:Unix]][[Category:Computing]]

Latest revision as of 11:58, 9 September 2006

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).