Yikes! Something strange in a cron job.

Richard Esplin richard-lists at esplins.org
Sun Feb 9 00:52:43 MST 2014


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 <sdalemorrey at gmail.com>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 
<sdalemorrey at gmail.com>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 
<joshua at themarshians.com>wrote:
> >>> On Sat, Feb 8, 2014 at 2:59 PM, S. Dale Morrey <sdalemorrey at gmail.com
> >>> 
> >>> >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>


More information about the PLUG mailing list