Yesterday I re-emerged sys-apps/util-linux and sys-apps/shadow to switch my 'su' executable over to the version provided by util-linux since the version provided by shadow has been deprecated. Today I got an email telling me the daily man-db cron job failed: run-parts: /etc/cron.daily/man-db exited with return code 1 There was no other output explaining why the cron job failed, but that's perhaps not surprising since that shell script redirects stderr to /dev/null: # cat /etc/cron.daily/man-db #!/bin/sh # 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 exec su man -s /bin/sh -c 'nice mandb --quiet' 2>/dev/null I get more information if I run the command myself (as root) without the redirection: # su man -s /bin/sh -c 'nice mandb' su: Authentication service cannot retrieve authentication info I'm not sure what the problem is since the 'man' user does exist: # fgrep man /etc/passwd man:x:13:15:System user; man:/dev/null:/sbin/nologin This was working fine with the 'su' from sys-apps/shadow.
Interesting. Fine for me: ``` # su man -s /bin/sh -c 'nice mandb' Purging old database entries in /usr/share/man... Processing manual pages under /usr/share/man... Processing manual pages under /usr/share/man/cat8... Purging old database entries in /usr/share/man/it... [...] ``` Could you share emerge --info sys-apps/util-linux? Wondering about USE=suid & USE=pam.
(In reply to Sam James from comment #1) > Could you share emerge --info sys-apps/util-linux? Wondering about USE=suid > & USE=pam. sys-apps/util-linux-2.37.2-r3::gentoo was built with the following: USE="cramfs hardlink logger ncurses pam readline (split-usr) su suid tty-helpers udev (unicode) -audit -build -caps -cryptsetup -fdformat -kill -magic -nls -python (-rtas) (-selinux) -slang -static-libs -systemd -test" ABI_X86="(64) -32 -x32" PYTHON_TARGETS="-python3_8 -python3_9"
PAM also sends logging messages to syslog. Does anything useful show up there?
I'm also hitting this issue. at each cron.daily execution, syslog has: Dec 26 03:37:02 server unix_chkpwd[13703]: could not obtain user info (man) Dec 26 03:37:02 server su[13702]: FAILED SU (to man) root on none
Which cron package are you using? What USE flags are enabled on said package?
Could you share the entry for the man user from /etc/shadow?
I can reproduce the issue by removing the entry for the man user from /etc/shadow. Is this entry missing on your system?
(In reply to Mike Gilbert from comment #7) > I can reproduce the issue by removing the entry for the man user from > /etc/shadow. > > Is this entry missing on your system? Yes, no man user in /etc/shadow. # equery u cronie [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-process/cronie-1.5.7: U I + + anacron : Install the periodic anacron command scheduler. + + inotify : Enable inotify filesystem monitoring support + + pam : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip #
(In reply to Aidan Marks from comment #8) > Yes, no man user in /etc/shadow. You can resolve that by running "pwconv" to populate any missing entries in /etc/shadow based on entries in /etc/passwd.
Thanks, pwconv fixed it, manual execution of exec su man -s /bin/sh -c 'nice mandb --quiet' now returns 0. Not sure how the missing man user shadow entry occured. This gentoo box is 11 years old though.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ba1318bc1779637a83319f05992a11e83b84069 commit 8ba1318bc1779637a83319f05992a11e83b84069 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-27 03:13:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-27 03:51:25 +0000 sys-apps/shadow: check for invalid passwd entries - In pkg_postinst, check for invalid ${EROOT}/etc/passwd entries by running 'pwck' in read-only mode. In the referenced bug, this manifested as the man cronjob failing. - Also fix another check for empty ${EROOT} (broken since EAPI 7 port). Closes: https://bugs.gentoo.org/829872 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/23534 Signed-off-by: Sam James <sam@gentoo.org> .../shadow/{shadow-4.10-r3.ebuild => shadow-4.10-r4.ebuild} | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
sys-apps/bas(In reply to Aidan Marks from comment #10) > Not sure how the missing man user shadow entry occured. This gentoo box is > 11 years old though. Even a brand-new Gentoo installation would be missing an entry for 'man' in /etc/shadow since that's how sys-apps/baselayout installs it. # cat /usr/share/baselayout/shadow root:*:10770:0::::: halt:*:9797:0::::: operator:*:9797:0::::: shutdown:*:9797:0::::: sync:*:9797:0::::: bin:*:9797:0::::: daemon:*:9797:0::::: adm:*:9797:0::::: lp:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: portage:*:9797:0::::: nobody:*:9797:0:::::
Begging your pardon. There's no 'man' user in baselayout's /etc/passwd either. Maybe some of us had our 'man' user added by Portage before shadow was installed? Is that possible?
(In reply to Matt Whitlock from comment #13) > Maybe some of us had our 'man' user added by Portage before shadow was > installed? Is that possible? Yeah, it must be something like that.
