# cron job not running



## Mike Z (Jan 28, 2018)

Hello all, 

I am trying to automate my backup tasks to by able to run rsync incremental backups daily. I am using the following command:
`rsync -av --delete /mnt/data/mirrorstorage /mnt/data/incrementalExternalBackup`

and I am adding it to crontab using the following with the intention of having the backup run at 3:00am:

```
0 3 * * * rsync -av --delete /mnt/data/mirrorstorage /mnt/data/incrementalExternalBackup
```
When I run the rsync command on its own I have no problem, but the entry in cron doesn't seem to be running. I'm fairly novice when it comes to *nix operating systems so I'm not sure if there is something easy I'm missing. From the guides I've read on rsync and automating rsync using crontab, what I'm doing should work.

Another thing I have tried is adding the rsync command I am using to a .sh script and calling that in crontab instead of the direct command itself, but I get the same results.

Any assistance would be greatly appreciated. Thank you in advance!


----------



## ShelLuser (Jan 28, 2018)

First: always check your e-mail. When a cron job produces an error then this will be e-mailed to the cronjob owner so that you can see what went wrong.

Although I personally doubt it I suppose it could have been a path related issue. To my knowledge /usr/local/bin as well as /usr/local/sbin are part of the default search path of cron (see crontab(5)). Even so it won't hurt to try and use the full path to rsync and see what happens next.

But once again: check your e-mail, that should tell you exactly what happened with this cronjob.


----------



## tobik@ (Jan 28, 2018)

ShelLuser said:


> To my knowledge /usr/local/bin as well as /usr/local/sbin are part of the default search path of cron (see crontab(5)).


Only on FreeBSD >= 11.0. On older versions it's still just /usr/bin:/bin


----------



## Mike Z (Jan 28, 2018)

ShelLuser thank you for that recommendation, that solved my problem. When I checked my email it said "rsync: not found" at the bottom of the message so I guessed that's what you were referring to regarding the full path to rsync. I checked the man page for rsync and found that the full path is /usr/local/bin/rsync, and once I started using that the backup started working.

So now the working crontab entry is:

```
0 3 * * * /usr/local/bin/rsync -av --delete /mnt/data/mirrorstorage /mnt/data/incrementalExternalBackup
```
It was also a good learning experience in figuring out how to use the mail client as I've never had to use it before. Thanks so much for the help!


----------



## phoenix (Jan 30, 2018)

Generally, you don't want to list bare commands in crontabs. Instead, create a shell script, and run your command(s) from there. The nice thing about this is that running it at the shell or via cron is a simple matter instead of copying and pasting.

It's also easier to expand to multiple commands in the future.

And you can control the environment better, providing full paths to things, or setting up paths, etc.

It also keeps the crontab looking nicer.


----------



## Mike Z (Jan 30, 2018)

Understood. I'll be modifying my earlier shell script with the full path to rsync and using that instead. Thank you for the pro-tip. I really appreciate the best-practice advise!


----------



## ralphbsz (Jan 30, 2018)

To expand on what phoenix said: Here's my convention, you can steal it if you like: I have really short scripts in /usr/local/sbin, which always start with "do_...".  So you could call your script "do_rsync", or even "do_incremental_backup".  Like that the name of the script indicates what the purpose is, and the "do_" prefix indicates that it isn't the real program that does the work, just the wrapper that makes it easily callable from cron.

Most of these scripts redirect their output to a log file, and internally handle all errors and leave the error output prominently in the log file.  On stderr, they then output just a single line in the error case.  Like that, the e-mail message from cron is very clear and concise: "Something went wrong in do_foo, please read /var/log/foo/20180127.log".

Similarly, I have scripts that clean up older log files, which are called "purge_...".


----------



## fullauto2012 (Jan 31, 2018)

ralphbsz said:


> To expand on what phoenix said: Here's my convention, you can steal it if you like: I have really short scripts in /usr/local/sbin, which always start with "do_...".  So you could call your script "do_rsync", or even "do_incremental_backup".  Like that the name of the script indicates what the purpose is, and the "do_" prefix indicates that it isn't the real program that does the work, just the wrapper that makes it easily callable from cron.
> 
> Most of these scripts redirect their output to a log file, and internally handle all errors and leave the error output prominently in the log file.  On stderr, they then output just a single line in the error case.  Like that, the e-mail message from cron is very clear and concise: "Something went wrong in do_foo, please read /var/log/foo/20180127.log".
> 
> Similarly, I have scripts that clean up older log files, which are called "purge_...".



Nice convention... 
*STEALING*


----------



## Mike Z (Jan 31, 2018)

That's great advice ralphbsz 
I'll be adopting that convention for sure. Thanks!


----------

