From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Root's crontab, /etc/crontab, defines HOME to be "/". This can cause some programs difficulty, for example autorpm <http://www.kaybee.org/~kirk/html/linux.html>. Root's actual home directory is "/root". Maybe /etc/crontab should define it that way. Reproducible: Always Steps to Reproduce: 1. As root, import the RPM PGP keys from /usr/doc/rpm-xx 2. Install Autorpm & configure /etc/autorpm.d/redhat-updates for automatic updates, with PGP signature checking 3. Let autorpm run from cron Actual Results: autorpm will fail to verify the signatures on the RPMs. However, when you log in as root and run autorpm manually with 'autorpm -- apply', it will be able to verify the signatures. Expected Results: Autorpm should have been able to invoke gpg seamlessly to check the validity of the packages. This fails because when autorpm tries to run gpg, HOME=/. When gpg was run earlier, it used HOME=/root to do its work. gpg will create a new, empty /.gnupg directory when run from cron, but it will not contain root's actual .gnupg directory. Red Hat should consider changing crontab's HOME to /root instead of /, unless this is considered a security flaw. This exists on at least Red Hat 7.0 and 6.2.
This was actually switched to / a few releases back. I don't recall why off the top of my head, but there was a reason. Will have to check into it.
FYI, this problem also impacts the MySQL package, last I checked. In order for the log rotate script to find the password file, I had to symlink /.my.cnf - > /root/.my.cnf
To fix this "problem", simply prepend: HOME=/root to your cron job, so the cron job would look like: * 12 * * * root HOME=/root autorpm or similar. We do not want whatever happens to be in ~root/{.login,.profile,.bashrc} to affect all cron jobs.