Even with USE=-pam openrc-0.44 builds with pam-support if sys-libs/pam is installed on the system. This leads to failures when starting some services, e.g. syslog-ng: * Starting syslog-ng ... * start-stop-daemon: pam error: Authentication failure * start-stop-daemon: failed to start `/usr/sbin/syslog-ng' I don't know why it doesn't effect all services, I know it does for app-admin/syslog-ng and net-dns/ddclient. Reproducible: Always Steps to Reproduce: 1. Install sys-apps/openrc-0.44.7 2. Restart app-admin/syslog-ng or net-dns/ddclient via rc-service Actual Results: # rc-service ddclient restart * Caching service dependencies ... [ ok ] * Stopping DDclient ... [ ok ] * Starting DDclient ... * start-stop-daemon: pam error: Authentication failure * start-stop-daemon: failed to start `/usr/bin/ddclient' * Failed to start DDclient [ !! ] * ERROR: ddclient failed to start Expected Results: # rc-service ddclient restart * Stopping DDclient ... [ ok ] * Starting DDclient ... I'll attach emerge info, the build log and a patch working for me.
Created attachment 747810 [details] emerge --info
I get a http status 500 server error commiting the build log, so here are the relevant lines: * Package: sys-apps/openrc-0.44.7 * Repository: gentoo * Maintainer: openrc@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc kernel_linux ncurses netifrc unicode userland_GNU * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking openrc-0.44.7.tar.gz to /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work >>> Source unpacked in /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work >>> Preparing source in /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7 ... >>> Source prepared. >>> Configuring source in /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7 ... meson setup --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path /usr/share/pkgconfig --pkg-config-path /usr/share/pkgconfig --native-file /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/temp/meson.x86_64-pc-linux-gnu.amd64.ini --buildtype plain -Daudit=disabled -Dbranding="Gentoo Linux" -Dnewnet=false -Dos=Linux -Dpam=false -Dselinux=disabled -Dshell=/bin/sh -Dsysvinit=false -Dtermcap=ncurses /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7 /var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7-build ^[[1mThe Meson build system^[[0m Version: 0.59.1 Source dir: ^[[1m/var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7^[[0m Build dir: ^[[1m/var/tmp/tmpfs/portage/sys-apps/openrc-0.44.7/work/openrc-0.44.7-build^[[0m Build type: ^[[1mnative build^[[0m Project name: ^[[1mOpenRC^[[0m Project version: ^[[1m0.44.7^[[0m C compiler for the host machine: ^[[1mx86_64-pc-linux-gnu-gcc^[[0m (gcc 11.2.0 "x86_64-pc-linux-gnu-gcc (Gentoo 11.2.0 p1) 11.2.0") C linker for the host machine: ^[[1mx86_64-pc-linux-gnu-gcc^[[0m ld.gold 2.37 Host machine cpu family: ^[[1mx86_64^[[0m Host machine cpu: ^[[1mx86_64^[[0m Dependency ^[[1maudit^[[0m skipped: feature ^[[1maudit^[[0m disabled Found pkg-config: ^[[1m/usr/bin/x86_64-pc-linux-gnu-pkg-config^[[0m (1.7.4) Run-time dependency ^[[1mpam^[[0m found: ^[[1;32mYES^[[0m ^[[36m1.5.1^[[0m Dependency ^[[1mlibselinux^[[0m skipped: feature ^[[1mselinux^[[0m disabled Run-time dependency ^[[1mncurses^[[0m found: ^[[1;32mYES^[[0m ^[[36m6.2.20210619^[[0m We see it's configured with -Dpam=false. Later on the build script finds pam although not requested and set's -DHAVE_PAM (not shown here, but we would see it set in the cc-calls later on).
Created attachment 747813 [details, diff] proposed patch The patch working for me. It sets -DHAVE_PAM only if pam had been requested.
I can confirm the issue and that the proposed patch alleviates it. Thanks, Walter! :)
I have the same issue and the proposed patch fixed it! Thank you!
Should we set the importance to high? This may brake remote systems if something like sshd isn't starting due to missing pam files.
At least please set it as confirmed.
(In reply to Walter Trautner from comment #7) > At least please set it as confirmed. UNCONFIRMED vs CONFIRMED doesn't really mean anything. Anyway, I pinged William, and he's working on a patch.
(In reply to Sam James from comment #8) > (In reply to Walter Trautner from comment #7) > > At least please set it as confirmed. > > UNCONFIRMED vs CONFIRMED doesn't really mean anything. Anyway, I pinged > William, and he's working on a patch. https://github.com/OpenRC/openrc/commit/9d4f11f726b39efc80aed3e57ef3d74d2a99b76e this may help, but he wants to test it first. Can you try it in /etc/portage/patches please?
(In reply to Sam James from comment #9) > (In reply to Sam James from comment #8) > > (In reply to Walter Trautner from comment #7) > > > At least please set it as confirmed. > > > > UNCONFIRMED vs CONFIRMED doesn't really mean anything. Anyway, I pinged > > William, and he's working on a patch. > > https://github.com/OpenRC/openrc/commit/ > 9d4f11f726b39efc80aed3e57ef3d74d2a99b76e this may help, but he wants to test > it first. Can you try it in /etc/portage/patches please? That's the provided patch and had been good so far. What else should we test?
(In reply to Walter Trautner from comment #10) > (In reply to Sam James from comment #9) > > (In reply to Sam James from comment #8) > > > (In reply to Walter Trautner from comment #7) > > > > At least please set it as confirmed. > > > > > > UNCONFIRMED vs CONFIRMED doesn't really mean anything. Anyway, I pinged > > > William, and he's working on a patch. > > > > https://github.com/OpenRC/openrc/commit/ > > 9d4f11f726b39efc80aed3e57ef3d74d2a99b76e this may help, but he wants to test > > it first. Can you try it in /etc/portage/patches please? > > That's the provided patch and had been good so far. What else should we test? Oh, sorry, I missed that (I'm not really involved with OpenRC, I just saw people being bothered by this and pinged about it)!
Thanks for the ping. This should be fixed in 0.44.8.
Can confirm it's fixed in 0.44.8.
(In reply to Walter Trautner from comment #13) > Can confirm it's fixed in 0.44.8. Thanks!
