Difference between revisions of "Shell Time-out"
(10 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 | [[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 | [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. | ||
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 | 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>): <nowiki> | # Add the following to the <tt>.bash_profile</tt> file (in <tt>~/.bash_profile</tt>): <nowiki> | ||
</nowiki><pre><nowiki> | </nowiki> | ||
<pre><nowiki> | |||
if [[ -n $TERM ]]; then | if [[ -n $TERM ]]; then | ||
if [[ -n $SSH_CLIENT ]]; then | if [[ -n $SSH_CLIENT ]]; then | ||
Line 43: | Line 45: | ||
</nowiki></pre> | </nowiki></pre> | ||
#Then save the following code as <tt>~/bin/sendnulls</tt> <nowiki> | #Then save the following code as <tt>~/bin/sendnulls</tt> <nowiki> | ||
</nowiki><pre><nowiki> | </nowiki> | ||
<pre><nowiki> | |||
#!/bin/bash | #!/bin/bash | ||
Line 53: | Line 56: | ||
</nowiki></pre> | </nowiki></pre> | ||
#finally add the following to ~/.bash_logout file. <nowiki> | #finally add the following to ~/.bash_logout file. <nowiki> | ||
</nowiki><pre><nowiki> | </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 63: | 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| | =={{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
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
- A X server Cygwin/X like running on my client machine.
- 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.
- 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
- 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
- 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
- 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!
- Creates a shell variable named SENDNULLS_PID storing the PID of the process running the sendnulls program.
- It starts the sendnulls program in background
- When we log out it simply stop the sendnulls program by killing the PID represented by
- Simply kill the sendnulls program, i.e. kill the PID in SENDNULLS_PID.