2

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.

  • Can you post the exact mysqldump command from the script, or at best the full script itself? – chaos Aug 4 '15 at 13:19
  • pls post the cron entry – klerk Aug 4 '15 at 13:27
  • 3
    You should probably remove sudo from the script: you are running it from root's crontab anyway, and sudo may not like running without a tty - see Why does cron silently fail to run sudo stuff in my script? – steeldriver Aug 4 '15 at 14:03
  • 1
    Revise cron file contents so that you record stdout+stderr "12 21 * * * /var/custom/maint_plan >/tmp/log.txt 2>&1". Also, would be good practice to add a #!/bin/bash to the start of your script. – steve Aug 4 '15 at 20:24
  • 1
    There was surely an error message to tell you what is wrong. Error messages from cron jobs are sent over local email. Make sure that you have local email set up and that you read it. – Gilles Aug 4 '15 at 23:05
2

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
1

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

  • Is there a log that I can inspect to determine the issue? – Roy Hinkley Aug 4 '15 at 13:22
  • The script executes properly when run manually. If it were a variable issue, would it not fail regardless of execution originator? – Roy Hinkley Aug 4 '15 at 13:27
  • I mean that arguments aren't passed correctly to the script when run via cron. Please post the content of your crontab file. – dr01 Aug 4 '15 at 13:29
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.