Shell script executed with cron results in different size file than executed manually

Question

I have a RHEL server that I am running a MySQL database on. I have a Bash script that executes mysqldump that creates a backup file. The backup file created when executing the script directly in Bash is 754259 bytes in size. If the same script is run via cron, it's only 20 bytes in size.

As far as I know, cron is running with the same user context that I use when logged in to run the script manually. However, given the size differential, that does not appear to be true.

Why are the file sizes different when running the same script?

The shell script contents:

backup_path=/var/custom/db_backups
configFile=/var/custom/auth.cnf
db_name=[db_name]
date=$(date +"%d-%b-%Y")

sudo /opt/rh/mysql55/root/usr/bin/mysqldump --defaults-extra-file=$configFile $db_name | gzip -9  > $backup_path/$db_name-$date.sql.gz

To edit cron:

sudo crontab -e

cron file contents:

12 21 * * * /var/custom/maint_plan

This executes the script daily at 9:13 PM.

Answer 1

The mysqldump command returns nothing, which is piped trough gzip and ends in an empty gzip file. See:

$ echo -n "" | gzip -9  > test.gz
$ stat -c %s test.gz
20

This results in a file with size 20 bytes. So the problem is the mysqldump command. Since it's root's crontab the script runs with root priviledges. sudo is not necessary. Use it without sudo. Just:

/opt/rh/mysql55/root/usr/bin/mysqldump --defaults-extra-file=$configFile $db_name | gzip -9  > $backup_path/$db_name-$date.sql.gz

Answer 2

The script run via cron is failing. 20 bytes is the size of an empty MySQL dump.

Answer 3

The environment that cron runs scripts in is very limited. It may not be finding all of the required programs. Capture the environment variables of the shell in which you get a good dump and carry that over to your cron script.