cron job not running

Mike Z

Mike Z

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:
Code: 
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! :D
 
Last edited by a moderator:
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.
 
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:
Code: 
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!
 
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. :D
 
Last edited:
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!
 
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_...".
 
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_...".
Click to expand...

Nice convention...
*STEALING*
 
You must log in or register to reply here.
Back
Top