Cron job not generating backups

What is the output of

sudo run-parts -v /path/to/cronfile

I've tried

$ sudo run-parts -v /var/spool/cron/crontabs/

but see no output. The other job in the crontab (that normally runs ok overnight) doesn't appear to have been fired by that use of run-parts. Maybe I've misunderstood what /path/to/cronfile should be?

Thanks,

David

If you make a bash script as below:

#!/bin/bash
/usr/sbin/automysqlbackup
echo "success" | tee -a /var/log/automysqlbackuplog.log

Does the file get made?

Be sure you cron as the right user too as this dictates access. If your user can run the command without sudo then use that. You can also run crontab as root using sudo.

I have created that bash script in my home directory, calling it testautomysqlbackup.sh.

I can run it with

$ sudo ./testautomysqlbackup.sh

and that gives an output of

success

generates backups, and creates the log file /var/log/automysqlbackup.log which contains the line

success

If I delete the log file and set up a cron job, for root, again using

sudo crontab -e

then the cron job generates the log file with the line

success

BUT backups don't appear to be created. I'm pretty sure the cron job is for root, because if I read the file /var/spool/cron/crontabs/root in an editor it has the same contents as the file brought up by "sudo crontab -e", and files created by other jobs in that crontab are owned by root.

If I run the script just as myself, with

$ ./testautomysqlbackup.sh

then the output is:

/usr/sbin/automysqlbackup: line 28: /etc/default/automysqlbackup: Permission denied
mkdir: cannot create directory `': No such file or directory
mkdir: cannot create directory `/daily': Permission denied
mkdir: cannot create directory `/weekly': Permission denied
mkdir: cannot create directory `/monthly': Permission denied
touch: cannot touch `/-633460796.log': Permission denied
/usr/sbin/automysqlbackup: line 402: /-633460796.log: Permission denied
touch: cannot touch `/ERRORS_-673658986.log': Permission denied
/usr/sbin/automysqlbackup: line 406: /ERRORS_-673658986.log: Permission denied
======================================================================
AutoMySQLBackup VER 2.5
http://sourceforge.net/projects/automysqlbackup/

Backup of Database Server -
======================================================================
Backup Start Tue May 20 16:20:11 UTC 2014
======================================================================
Daily Backup of Databases ( )

Rotating last weeks Backup...

touch: cannot touch `/daily/2014-05-20_16h20m.Tuesday.sql': No such file or directory
chmod: cannot access `/daily/2014-05-20_16h20m.Tuesday.sql': No such file or directory
/usr/sbin/automysqlbackup: line 415: [: =: unary operator expected
/usr/sbin/automysqlbackup: line 422: /daily/2014-05-20_16h20m.Tuesday.sql: No such file or directory
No compression option set, check advanced settings
----------------------------------------------------------------------
Backup End Time Tue May 20 16:20:11 UTC 2014
======================================================================
Total disk space used for backup storage..
Size - Location
du: invalid zero-length file name

======================================================================
If you find AutoMySQLBackup valuable please make a donation at
http://sourceforge.net/project/project_donations.php?group_id=101066
======================================================================
cat: /-633460796.log: No such file or directory
tee: /var/log/automysqlbackup.log: Permission denied
success

which, apart from the last two lines about tee and success, is basically the same output as when I run

$ /usr/sbin/automysqlbackup

Therefore I think /usr/sbin/automysqlbackup needs to be run by root, rather than by my user.

When running /usr/sbin/automysqlbackup via cron rather than manually through the command line, are there any extra parameters that need to be passed in? Any environmental variables it might be missing?

Thanks,

David

I noticed that when I run

crontab -e

the instructional text at the top includes "Output of the crontab jobs (including errors) is sent through email to the user the crontab file belongs to (unless redirected)."

So, I have looked in the file /var/mail/root and found the following emails from Cron Daemon:

Subject: Cron <root@myserver> /usr/sbin/automysqlbackup
Content-Type: text/plain; charset=ANSI_X3.4-1968
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Subject: Cron <root@myserver> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
Content-Type: text/plain; charset=ANSI_X3.4-1968
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>

/etc/cron.daily/automysqlbackup:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

The first one is from the cron job I set up, the second must be from a cron job created when the automysqlbackup package was installed.

I wonder if it is related to the fact that I get the same error when I run

$ mysql -u root -p

but I can access mysql ok with:

$ mysql -u root -p -h 127.0.0.1

Any suggestions?

Thanks,

David

I notice that if I switch to the root user before running mysql, by doing either

$ sudo su
$ mysql -u root -p

or just

$ sudo mysql -u root -p

then I don't get the error (I don't need to use the -h parameter). Is that a clue to some change in environment variables if that parameter isn't needed?

I think I may have solved the problem. I have added the -h parameter to the call to MySQL in the DBNAMES setting found in /etc/default/automysqlbackup. It now looks like

DBNAMES=`mysql --password=mypassword -h 127.0.0.1 --execute="SHOW DATABASES" | awk '{print $1}' | grep -v ^Database$ | grep -v ^mysql$ | tr \\\r\\\n ,\ `

Running /usr/sbin/automysqlbackup from root's crontab now appears to work ok.