Re: [Duplicity-talk] Duplicity (GPG) fails in crontab only

[Grant]

>>> Typically things fail in cron due to the relatively sterile
>>> environment that cron jobs inherit, although this failure
>>> sounds like gpg is unable to find the key rings.  Are
>>> the key files in ~root/.gnupg/?
>>
>>
>> The keys are in /root/.gnupg and I just noticed that mysqldump also
>> fails in my cron script and works fine when I run it manually.  Here's
>> the error:
>>
>> mysqldump: Got error: 1045: Access denied for user 'root'@'localhost'
>> (using password: NO) when trying to connect
>>
>> I have the password in /root/.my.cnf.
>>
>>
>>> My idiom for testing cron script manually is to become
>>> root (or whatever other user the cron job is to run as)
>>> with su.  then "env -i bash -norc".
>>
>>
>> I tried that with mysqldump and indeed I do get the access denied
>> error with the env and not without.  Where should I look to find the
>> problem?  (I'm keeping that env command, thanks.)
>
> env command with no args will list the current environment.  So
> logged in as root (in the state where the programs work) use it
> to list the env vars and look for likely suspects.
>
> One you've found the needed variable(s) you can add them to the
> crontab with lines of the form:
>
> ENVNAME=value


Should I be able to test that with 'env -i bash -norc'?  I've added
all of the variables I get from env when the command works to the 'env
-i bash -norc' environment but the command still doesn't work.
Running 'env' in the 'env -i bash -norc' environment doesn't list the
added variables but echo does return their values.

- Grant