Cronjob SH script not running

M

marvel

Hi,

I am trying for a long time now to get cron to execute my .sh backup script. All other cronjobs run, including some PHP CLI scripts I have running but my bash script fails every single time. No error nothing, it just doesn't execute.

I have this line in my crontab (root):
Code: 
0 8 * * * /bin/bash /root/backup.sh > /root/backup.log
I tried with and without /bin/bash, doesn't make a difference. The backup.log is created but has no content. All the script does is execute rsync commands, when I run it manually it runs fine (which I have to do now since cron doesn't do it).

My /var/log/cron says this:
Code: 
Mar 14 08:00:00 roubaix01 /usr/sbin/cron[54211]: (root) CMD (/bin/bash /root/backup.sh > /root/backup.log)
So it does seem like it's executing it, however it's not executing the contents of the script which contains 4 commands

rsync -av......etc.

Any idea?

Thanks!
 
FreeBSD doesn't have bash installed by default, so there is no /bin/bash. If you install shell/bash it will be /usr/local/bin/bash. But I suggest not installing bash for such a simple script and use /bin/sh.
 
Unless you have messed with the PATH setting at the top of /etc/crontab (which you probably shouldn't), make sure any commands in your script that live under /usr/local have the full path specified. (In fact it's probably good practice to specify the full path for all commands).

i.e. change
Code: 
rsync -av
into
Code: 
/usr/local/bin/rysnc -av

If you use the first method above, the system won't be able to find rsync, as the PATH list used by cron is fairly restrictive.
 
Last edited by a moderator:
wblock@ said:
marvel said:
I have both /bin/bash and /usr/local/bin/bash.
Click to expand...

The shells/bash port does not install a link in /bin, as far as I know. Unless I'd done that myself (I wouldn't), how it got there would be a concern.
Click to expand...

It's a symbolic link, I don't know if I did that myself but it could be.
 
Last edited by a moderator:
usdmatt said:
Unless you have messed with the PATH setting at the top of /etc/crontab (which you probably shouldn't), make sure any commands in your script that live under /usr/local have the full path specified. (In fact it's probably good practice to specify the full path for all commands).

i.e. change
Code: 
rsync -av
into
Code: 
/usr/local/bin/rysnc -av

If you use the first method above, the system won't be able to find rsync, as the PATH list used by cron is fairly restrictive.
Click to expand...

I didn't know the cron path was different because when I type rsync as a user it just works, but this was the solution. I added the full path to rsync and now it works, thanks!
 
Last edited by a moderator:
Can any of you fine fellows suggest a couple of great 'intermediate' skill level script writing cook books, that include tying this in with cron? Any of those FreeBSD books you folks suggested to me earlier this year include a decent chapter on script writing?
 
marvel said:
Hi,

I am trying for a long time now to get cron to execute my .sh backup script. All other cronjobs run, including some PHP CLI scripts I have running but my bash script fails every single time. No error nothing, it just doesn't execute.

I have this line in my crontab (root):
Code: 
0 8 * * * /bin/bash /root/backup.sh > /root/backup.log
Click to expand...

Stop right there! You are doing something fundamentally wrong! Do you know what it is? You are editing the system /etc/crontab instead of creating a new one for the root user: crontab -e.

Make sure you are using tabs as separator. /bin/bash is not a path to a third party shell. It is in /user/local/bin/bash. The way to specify the shell is at the beginning of the crontab file. There is an environmental variable for that.
Finally that is not the shell script! It is a bash script. So I hate to see that .sh extension.
 
If the original poster was editing the system wide crontab file rather than root's then it wouldn't run since the user field is not filled in. And bash is a shell so a bash script is a shell script.
 
NewGuy said:
If the original poster was editing the system wide crontab file rather than root's then it wouldn't run since the user field is not filled in.
Click to expand...
+1 You are right about that of course! I have seen why too many Linux guys editing system crontab files to pay attention to the user field.
 
You must log in or register to reply here.
Back
Top