When you first posted, I vaguely remembered hitting this problem a couple of times before. But your latest post jogged my memory.
Cron doesn't allow initialize any environment for the commands that it triggers.. When I want to run a command in a specific environment, I write a wrapper script to call the command. As a bonus, you can drop the script into the right cron.d directory for when you want it run, and not have to worry about editing crontab. The script will have the same permissions as crontab, so your DB credentials will have the same level of security. Cheers, Richard On Saturday, February 08, 2014 18:12:58 S. Dale Morrey wrote: > The only solution I was able to find that actually worked was specifying > the variables inside the script directly. > I do not like this option. Any user (authorized or not), would get the DB > credentials in plain text if they happened to run ps aux at the right > moment in time. :( > > On Sat, Feb 8, 2014 at 3:19 PM, S. Dale Morrey <[email protected]>wrote: > > Hmm setting HOME explicitly now causes the command to fail even when > > logged in as root and running it directly... > > Curiouser and curiouser... > > > > On Sat, Feb 8, 2014 at 3:16 PM, S. Dale Morrey <[email protected]>wrote: > >> Yeah it is wrapped up in a script already. But thanks, I'm setting the > >> HOME variable and seeing if that works. > >> > >> On Sat, Feb 8, 2014 at 3:14 PM, Joshua Marsh <[email protected]>wrote: > >>> On Sat, Feb 8, 2014 at 2:59 PM, S. Dale Morrey <[email protected] > >>> > >>> >wrote: > >>> > This makes me wonder if I need to specify HOME as in "export > >>> > >>> HOME=/root" > >>> > >>> > I'm going to give that a shot and see if it solves the problem. > >>> > >>> It may depend on what version of cron you have installed. Here is what > >>> mine > >>> > >>> says about it: > >>> Several environment variables are set up automatically by the > >>> > >>> cron(8) daemon. SHELL is set > >>> > >>> to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd > >>> line > >>> > >>> of the crontab's owner. > >>> > >>> PATH is set to "/usr/bin:/bin". HOME, SHELL, and PATH may be > >>> > >>> overridden by settings in the > >>> > >>> crontab; LOGNAME is the user that the job is running from, and > >>> may > >>> > >>> not be changed. > >>> > >>> When I had a problem like this before, the thing that fixed it for me > >>> was > >>> to wrap the command in a script. So, your cron entry might be: > >>> > >>> 0 1 * * * /bin/bash /root/backup_mysql.sh > >>> > >>> and then your script would simply be: > >>> > >>> #!/bin/bash > >>> mysqldump dbname > >>> > >>> I never figured out the actual problem, but I'm sure it was related to > >>> environmental variables like you suggest or perhaps the difference > >>> between > >>> /bin/sh and /bin/bash. <snip> /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
