# Cronjob SH script not running



## marvel (Mar 14, 2014)

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):

```
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:

```
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!


----------



## worldi (Mar 14, 2014)

Are you sure /bin/bash is correct? It's /usr/local/bin/bash by default.


----------



## SirDice (Mar 14, 2014)

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.


----------



## marvel (Mar 14, 2014)

I have both /bin/bash and /usr/local/bin/bash.

I'll try with sh thanks.


----------



## usdmatt (Mar 14, 2014)

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

```
rsync -av
```
into

```
/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.


----------



## wblock@ (Mar 14, 2014)

marvel said:
			
		

> I have both /bin/bash and /usr/local/bin/bash.



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.


----------



## marvel (Mar 17, 2014)

wblock@ said:
			
		

> marvel said:
> 
> 
> 
> ...



It's a symbolic link, I don't know if I did that myself but it could be.


----------



## marvel (Mar 17, 2014)

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
> 
> ...



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!


----------



## phoenix (Mar 17, 2014)

Please read the Interrupted UNIX Faq.  Especially number 2.     B-)


----------



## PacketMan (Nov 23, 2014)

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?


----------



## Oko (Nov 23, 2014)

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.
> 
> ...



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.


----------



## NewGuy (Nov 24, 2014)

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.


----------



## Oko (Nov 24, 2014)

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.


+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.


----------

