-   Linux - General (
-   -   Calling Crontab over non interactive ssh session (

IgnitusBoyone 06-08-2011 12:49 PM

Calling Crontab over non interactive ssh session
Ok, is there any obvious reason like security permissions why the following script would fail when executed over ssh with a supplied command



crontab -l > crontab.bak
cp crontab.bak crontab
echo " 30 2 * * * /usr/local/bin/targetprogram 2>&1" >> crontab
crontab crontab

This simple would be called using

ssh user@host
The file was put in place prior to the attempt to run it remotly. Essentially I had over 100 servers where I needed to make a crontab update, using a usr who doesn't have admin access. Now the script works in an interactive ssh session just fine, but when ran as stated above in a non interactive mode it produced crontab.bak dorrectly and modified the new crontab file correctly, but the entry in cron was empty. This leads me to believe the line "crontab crontab" failed due to some permission or enviroment issue I am unaware of.

If you have any feedback I would greatly appriciate it and if you have a better idea on how to automate commands like this when pushing to multiple servers I'm all ears.

szboardstretcher 06-08-2011 12:51 PM

name the file 'newcrontab' instead of crontab

anything in /var/log/messages or /var/log/cron ?

IgnitusBoyone 06-08-2011 01:13 PM

I'll test renaming the script in a few minutes and get back to you.

As for as the log request. For some reason the team in charge of the RH images puts var/log as 600 root root making my ability to look at the logs a very leangthy process. I'll work on that because it isn't something I thought about last night when I ran in to the trouble.

Reuti 06-08-2011 01:26 PM

I would assume that the PATH is different whether you get an interactive or batch session. Can you please check whether itís in your PATH also when invoked remotely:

$ ssh user@host which
Maybe ~/.bashrc and/or ~/.bash_profile needs to be adjusted.

NB: You can also avoid your own temporary file:


if [ "$PARAMETER" ]; then
    echo "$PARAMETER" >> $1
    export EDITOR=$0
    export PARAMETER="$1"
    crontab -e

and on the local machine then:

$ ssh user@host /home/user/ '" 30 2 * * * /usr/local/bin/targetprogram 2>&1"'
$1 during the second invocation is the name of the temporary file crontab -e normally feeds to the editor. Instead of the echo used here, you can also make more complex changes using sed or awk.

IgnitusBoyone 06-08-2011 04:07 PM

You were right. It was a path issue. The file provided need to be explicitly stated. I actually went ahead and used your version for future udpates because it makes it easier. I appriciate the help.

As a second note. I would have never thought about a recursive call to the same script. I like the technique and will need to find more ways to use it in the future.

Reuti 06-09-2011 04:22 AM

Great that it works now.

All times are GMT -5. The time now is 08:24 PM.