I never googled an answer to this, but I found what may be why:
From: Eric Moore (*****) Date: Tue Jul 08 2003 - 16:14:34 CDT If I run, root #> mysqladmin refresh it runs properly, reading the root password from .my.cnf. If I run the same from the crontab: 52 20 * * * /usr/local/bin/mysqladmin refresh /usr/local/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user: 'rootlocalhost' (Using password: NO)'
Even calling a script from crontab, mysqldump doesn't use find the ~/.my.cnf so it does (Using password: NO) It appears that when the commands are evoked from the cron that the environmental variable $HOME is unknown. So if you can pass HOME=/root before running mysqladmin or mysqldump in your script or command line then it may can find ~/.my.cnf I think a command done by cron does not know $HOME, probably good security for cron tasks to not pick up the environment of user? I am not sure if setting $HOME for a script called by cron is a security problem. But this way I think you can put the mysql password in ~/.my.cnf and run mysql commands with cron. HOpe that helps others who had problems with cron and mysqldump finding the password file. notes: ----------------------- crontab -l | grep mysqlbackup 10 23 * * * /storage/mysqlbackup 2>&1 # cat ~/.my.cnf [client] host=localhost user=root password=password # cat /storage/mysqlbackup #!/bin/sh HOME=/root THENAME=`/bin/hostname` THEDATE=`date +%Y%m%d%H%M` touch /storage/$THENAME.$THEDATE.mysql.gz chmod 700 /storage/$THENAME.$THEDATE.mysql.gz /usr/local/bin/mysqldump -aA |\ /usr/bin/gzip > /storage/$THENAME.$THEDATE.mysql.gz exit 0
