Difference between revisions of "Shell Time-out"
Line 73: | Line 73: | ||
=={{Subscript|Acknowledgements}}== | =={{Subscript|Acknowledgements}}== | ||
{{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).}} | ||
Revision as of 00:41, 6 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 habid 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.
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
- 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 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.
- 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.