Why does having cron run a remote command over ssh on a Cisco router get interrupted?

[vzvonarov1]

I'm dealing with a Cisco 3925 router at work.

I'm trying to run a ping command on it over ssh from home as part of a bash script on a Linux machine.

My bash script looks like this:

ssh user@3925_router 'ping Server_IP' 2>/dev/null | grep -q ' 0 percent'

if [ $? = 0 ]
then
    #Server is not responding
else
    #Server is responding
fi

This works great when I run it manually, but having cron run the script fails.

After some digging, it turns out that when I run the script manually, the ssh command returns this:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to SERVER_IP, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

but if I have cron run the script, the ssh command returns this:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to SERVER_IP, timeout is 2 seconds:
!

Which breaks my script. Any idea why having cron run a bash script with an ssh command would show a different result than running the script manually?

Note: If it helps, this is the ssh command running without cron, and this is it running with cron.

Thanks

[xthuijs]

hi there,

cron runs asynchronously, so it will invoke one sequence and already working on the next one,

or before it got a chance to spit the output it got finished/aborted already.

so you'll need to use flock or ';' to run synchronously and sequentially.

another option is using IPSLA as a probe for the server reachablility and have IPSLA spit a trap or syslog when it fails, this way it is on box and you dont have to mess with cron?

cheers

xander

[vzvonarov1]

Thanks for the reply

I did a search for "cron asynchronous" online, and it appears that cron's asynchronous nature has more to do with the fact that if you have it run a script, say every minute, and the script takes longer than a minute to complete, cron will run a second instance of the script while the first is still running. Some people suggest using flock to prevent this. Unless I'm wrong, this does not sound like it would have an impact on cron's ability to wait for a single command to complete within a script it's running. In fact, I can't think of a single good reason for anything that executes bash/sh scripts to ever skip ahead to the next command within the script, or interrupt a command, as bash/sh scripts are written to be procedural, and execute sequentially. Skipping ahead is a good way to destroy pretty much any bash script that wasn't specifically written to run things in parallel.

IPSLA seems interesting from what little I just read about it, but I'm afraid as I have little experience with it, and have no physical access to the router I'm working with (which is located pretty much in the middle of nowhere, hundreds of miles from civilization), if anything was to go wrong, it could mean that several hundred people will lose internet until I, or one of my team members can fly out there to fix it. This could take days, and cost hundreds, if not thousands of dollars, so I'd rather not experiment with a production router. I could probably do some experimenting with IPSLA on GNS3 first, but I'd rather figure out why cron has problems running ssh the way I want, especially since this is something I might run into again in the future.

For now, instead of cron, I setup a while loop in GNU Screen to run the script once per minute. This works, but I'm still curious why cron doesn't.

[xthuijs]

ha yeah I am not claiming to a unix expert by any stretch of the imagination, but that has been my experience with CRON that operates exactly as we're discussing which apparently is the intended nature. Other then the flock or ';' I am not aware of any good workarounds that have served me well in the past. It might be good to check some online forum focussing on linux OS itself or cron how to prevent it or what else can be done.

CRON is not very suitable for sync operations like do a command and wait for the result before doing something else. It would definitely serve a purpose for multi-task operations definitely!

Another fav of mine is Python, perl and expect for these type of operations. Especially expect is very easy and good for this purpose.

For IPSLA instead of running the probe on the device in question directly you could also take a cheap device connecting OFF that router and run the probe from there, I think a cheap 800 series from ebay will do that trick for you.

cheers

xander