[CentOS] cron job not running

Mon Mar 5 18:24:00 UTC 2012
Lists <lists at benjamindsmith.com>

On 03/04/2012 07:25 PM, Tim Dunphy wrote:
> hello list,
>
>   I am attempting to backup a centos 5.4 (x86_64) server running mysql
> with a cron job. Here's how the cron job looks:
>
>   [root at cloud:/home/bluethundr/backupdb] #crontab -l
> * 3 * * * /usr/bin/mysqldump jfwiki>
> /home/bluethundr/backupdb/wiki-$(date +%Y%m%d).sql
>
> However if I run the command from the command line it seems to work fine.
>
>
> If I grep syslog for cron this is what I've found:
>
> Mar  4 22:12:13 domU-12-31-38-07-49-CC syslog-ng[1174]: Log
> statistics; processed='center(queued)=16141',
> processed='center(received)=16141', processed='destination(d_boot)=0',
> processed='destination(d_auth)=3',
> processed='destination(d_cron)=131',
> processed='destination(d_mlal)=0', processed='destination(d_kern)=0',
> processed='destination(d_mesg)=200',
> processed='destination(d_cons)=0', processed='destination(d_spol)=0',
> processed='destination(d_mail)=15807', processed='source(s_sys)=16141'
>
> I've tried bouncing the crond service but even if I set the cron job
> to run every minute the backups don't run.
>
> I was hoping someone out there might have some advice n how to solve
> this problem.
>
> thanks

I'll start by suggesting that you really don't want to backup every 
minute - as soon as the data size grows bigger than what can be dumped 
in a minute, you're going to run into some serious problems. We backup 
all our databases hourly to avoid these types of problems, and a typical 
backup time is about 15-20 minutes.

I suggest taking your command and putting it into its own shell script. 
Call every command explicitly - full path as returned by which, eg: 
/usr/bin/mysqldump instead of just mysqldump, /bin/date instead of date, 
since cron runs with different environment variables. The crontab entry 
should also reference the full path to the script EG: 
/usr/local/bin/mysql_backup.sh instead of mysql_backup.sh - this also 
provides some security benefits since if you have the permissions 
straight, you won't inadvertently run the wrong script (perhaps 
containing an exploit) due to an unexpected problem with either the 
environment or inadvertent write permissions on the wrong directory.

Also, don't run this as root. Not that you can't, it just causes the 
script to run with more privileges than are strictly necessary. Add a 
user "mysqldump" or something and run the script in that user's crontab. 
I'd recommend that you don't give this user a password so it can't be 
inadvertently used against you.

Lastly, have your backup script produce some output at the end, EG: echo 
"Script complete" and then check the email of the user running the cron job.

My $0.02, good luck!