On a fresh system, my /var/cache/man is owned by shutdown:root, so as a result, running the man-db which comes with cronie by default (I think) fails, because it checks if the directory exists and then fixes the permissions, then runs mandb --quiet. As a result, you will get errors (by default on email) such as: root@rzski cron.daily # ./man-db fopen: Permission denied Reproducible: Always Steps to Reproduce: root@rzski cron.daily # ./man-db fopen: Permission denied root@rzski cron.daily # cat man-db #!/bin/sh # Use same perms/settings as the ebuild. if [ ! -d /var/cache/man ]; then mkdir -p /var/cache/man chown man:root /var/cache/man chmod 2755 /var/cache/man fi exec nice mandb --quiet root@rzski cron.daily # chown man:root /var/cache/man root@rzski cron.daily # chmod 2755 /var/cache/man root@rzski cron.daily # ./man-db root@rzski cron.daily #
Not cronie's fault: # qfile -C /etc/cron.daily/man-db sys-apps/man-db (/etc/cron.daily/man-db)
Thanks, fixed title.
By "fresh system", do you mean from an unpacked stage3 tarball? If so, I suspect something is setting the wrong owner for /var/cache/man during the stage building process.
(In reply to Mike Gilbert from comment #3) > By "fresh system", do you mean from an unpacked stage3 tarball? > > If so, I suspect something is setting the wrong owner for /var/cache/man > during the stage building process. Apologies, I can only assume that's what it is on linode, I just got a VPS from them.
(In reply to Patryk Rzadzinski from comment #4) > Apologies, I can only assume that's what it is on linode, I just got a VPS > from them. A recent stage tarball has the correct permissions, so this is probably an issue specific to your hosting provider. % tar -tvf stage3-amd64-20150416.tar.bz2 | grep -F /var/cache/man drwxr-sr-x man/root 0 2015-04-16 00:27 ./var/cache/man/ -rw-r--r-- root/root 0 2015-04-16 00:27 ./var/cache/man/.keep_sys-apps_man-db-0
we had the ebuild reset perms in the past as part of upgrades/migrations, but i don't recall the ownership of the dirs ever being "shutdown" the perm setup in the cronjob is meant for cases where /var gets nuked, not for when the perms get fudged. i'm not sure we generally support that case as it's hard to tell when it was accident (eh?) or on purpose because the admin is trying to do something different.
*** Bug 584198 has been marked as a duplicate of this bug. ***
