/etc/cron.daily/man-db ends with the line exec su man -s /bin/sh -c 'nice mandb --quiet' 2>/dev/null However, on this system there is no "su" installed due to sys-apps/util-linux[-su] and sys-apps/shadow[-su], and hence it fails with the following log message: run-parts: /etc/cron.daily/man-db exited with return code 127
This is technically an optional runtime dependency. If you don't use the cron job, you don't need 'su'. Given that most users will have 'su' installed by default, I don't really think we need to do anything here.
(In reply to Mike Gilbert from comment #1) > This is technically an optional runtime dependency. If you don't use the > cron job, you don't need 'su'. Yes, but as far as I can tell, man-db seems to enable this by default. At least I can't currently remember opting in, nor having seen any notice about this being optional. Either way, this causes a daily error message in the logs. What is the official suggested way to disable this cronjob and prevent these errors in the logs? > Given that most users will have 'su' installed by default, I don't really > think we need to do anything here. Although I might only represent the small minority of Gentoo users, I'm pleading You to take my case into account. For this to be truly optional, I propose adding a "cron" USE-flag (enabled by default) to install /etc/cron.daily/man-db and pull in the proper runtime dependencies. Thanks! :)
(In reply to Jaak Ristioja from comment #2) > What is the official suggested way to disable this cronjob and prevent these > errors in the logs? chmod -x /etc/cron.daily/man-db > For this to be truly optional, I propose adding a "cron" USE-flag (enabled > by default) to install /etc/cron.daily/man-db and pull in the proper runtime > dependencies. That would violate Gentoo policy, and I don't see a strong reason to do so. https://projects.gentoo.org/qa/policy-guide/dependencies.html#pg0001
(In reply to Mike Gilbert from comment #3) > That would violate Gentoo policy, and I don't see a strong reason to do so. Interesting policy. Given there were no good solutions to the underlying problem, I understand that a decision still had to be made. So although I disagree with that outcome, you've made a fair argument. Then how about one of these alternatives: 1) Make man-db unconditionally depend on su, perhaps introducing a virtual/su package. 2) Make /etc/cron.daily/man-db a no-op if su is not installed (i.e. no side-effects AND no error message in the logs) and during installation notify the user to install su to make it work. 3) Make /etc/cron.daily/man-db non-executable by default, and notify the user that installing su and a chmod +x is needed to make it work.
man-db upstream now ships a tmpfiles entry, making this, # Use same perms/settings as the ebuild. cachedir="/var/cache/man" if [ ! -d "${cachedir}" ]; then mkdir -p "${cachedir}" chown man:man "${cachedir}" chmod 0755 "${cachedir}" fi redundant in the cron job. And once the cron job consists of only, exec su man -s /bin/sh -c 'nice mandb --quiet' 2>/dev/null it's rather extravagant to use "su" as root to accomplish it. All cron implementations in the tree support dropping an entry in /etc/cron.d that launches the job directly as the "man" user. That wasn't the case in... 2018? Because vixie-cron. But it is now.
If someone wants to create/test a cron.d file to replace the cron.daily script, that seems like an nice solution to me. I use systemd and don't have a cron daemon installed, so I can't easily test it. Feel free to push it if you have commit access, or provide a patch/github PR otherwise.
