Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
On 09.07.2012 11:21, Teodor MICU wrote: 2012/7/9 Tollef Fog Heen tfh...@err.no: I think what might have happened is an aborted upgrade, which I don't think we currently handle correctly. I'll have to take a look at the code in question, though. I think we handle the pam-auth-update bits as suggested by the pam documentation. We run pam-auth-update --package in postinst, at that point the package should be fully installed/unpacked. I'm still unsure about the sequence of events that happened that led to this situation. Especially in what state the libpam-systemd package was in. Or were you talking about the removal of the lsb hook diversion? My guess is that this problem was caused by a deadlock in the upgrade. The packages were upgraded and started to execute the post-install configuration. But one of these packages (clamav-freshclam) has failed to configure (due to missing init-functions script) and the process was aborted, thus systemd packages didn't get configured either. To conclude, I see two problems to get fixed: - make sure as early as possible on package install/upgrade that the diversion is removed (probably pre-inst) - make sure on package removal that the diversion is removed (probably pre-rm). The /lib/lsb/init-scripts diversion is gone and has been replaced by the /lib/lsb/init-functions.d/40-systemd snippet. So all problems regarding diversions should be fixed. Unless there is a problem how we handle the removal of the old diversion in systemd.preinst? But this looks fine to me. That said, if there is a problem wrt /lib/lsb/init-functions, then this is a different issue, even if those two issues might be related. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
2012/7/9 Michael Biebl bi...@debian.org: Teodor, could you attach the output of debconf-show libpam-runtime please. Do you remember editing /etc/pam.d/common-session by hand? No, I don't think that's the case as showed in a previous message were a manual execution works properly. The issue is probably that the code was not executed. root@frost:~# debconf-show libpam-runtime libpam-runtime/override: false libpam-runtime/conflicts: libpam-runtime/no_profiles_chosen: libpam-runtime/profiles: unix, winbind, gnome-keyring, consolekit libpam-runtime/you-had-no-auth: libpam-runtime/title: Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
2012/7/9 Tollef Fog Heen tfh...@err.no: I think what might have happened is an aborted upgrade, which I don't think we currently handle correctly. I'll have to take a look at the code in question, though. My guess is that this problem was caused by a deadlock in the upgrade. The packages were upgraded and started to execute the post-install configuration. But one of these packages (clamav-freshclam) has failed to configure (due to missing init-functions script) and the process was aborted, thus systemd packages didn't get configured either. To conclude, I see two problems to get fixed: - make sure as early as possible on package install/upgrade that the diversion is removed (probably pre-inst) - make sure on package removal that the diversion is removed (probably pre-rm). Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
On Tue, Jul 03, 2012 at 12:23:54AM +0200, Michael Biebl wrote: This is probably from this line in /etc/pam.d/common-session: | session optionalpam_systemd.so I suspect you have told pam that you want to manage common-session by hand, else this is a bug in pam-auth-update, since the postinst just says: if [ $1 = remove ] ; then pam-auth-update --package --remove systemd fi Right, the issue is, that we switched to multiarch paths in 44-3. What does this have to do with multiarch paths? The module path shouldn't have been embedded in the pam-auth-update profile anyway - was it? I think pam-auth-update should handle that correctly, i.e. update the paths in the pam configuration even if the pam-configs snippet hasn't changed. There should be *no* paths in the configuration, therefore there should be nothing to update. You should use unqualified module names and trust pam's internal path - which AFAICS is what is done here. Steve, can you confirm that this should work? Is there an easy way to check if the pam configuration is managed manually and not by pam-auth-update? I believe this is stored in debconf as libpam-runtime/override. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
On 09.07.2012 02:54, Steve Langasek wrote: On Tue, Jul 03, 2012 at 12:23:54AM +0200, Michael Biebl wrote: Right, the issue is, that we switched to multiarch paths in 44-3. What does this have to do with multiarch paths? The module path shouldn't have been embedded in the pam-auth-update profile anyway - was it? [..] There should be *no* paths in the configuration, therefore there should be nothing to update. You should use unqualified module names and trust pam's internal path - which AFAICS is what is done here. Yeah, I'm really sorry for all the noise. The issue is most certainly not about multiarch paths. What seems to be the problem here is that Teodor has libpam-systemd no longer installed but there is still a corresponding line in common-session. As Tollef already mentioned, this should only happen if Teodor chose to manage common-session by hand. Otherwise pam-auth-update --package --remove systemd would have removed it. (assuming there isn't a bug in pam-auth-update) Teodor, could you attach the output of debconf-show libpam-runtime please. Do you remember editing /etc/pam.d/common-session by hand? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
On 03.07.2012 10:17, Teodor MICU wrote: if [ $1 = remove ] ; then pam-auth-update --package --remove systemd fi Can you please verify? I don't think this is the case. Executing that command manually works just fine: [..] The problem might be that the above script was not executed on removal? (ie. postrm or something) It is called in prerm, which means it's called on removal. So far this problem is unfortunately not reproducible here. Tollef, the only issue I see is that libpam-systemd is missing a dependency on libpam-runtime (= 1.0.1-6), which we should add in any case. That said, it is most unlikely though that Teodor did not have libpam-runtime installed when he removed libpam-systemd (as this would have generated a failure due to the missing pam-auth-update). If pam-auth-update --package --remove systemd did not trigger a warning about locally modified configuration, I'm a bit at a loss here what could have caused the problem for Teodor. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
]] Michael Biebl What seems to be the problem here is that Teodor has libpam-systemd no longer installed but there is still a corresponding line in common-session. I think what might have happened is an aborted upgrade, which I don't think we currently handle correctly. I'll have to take a look at the code in question, though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
2012/7/2 Tollef Fog Heen tfh...@err.no: I suspect you have told pam that you want to manage common-session by hand, else this is a bug in pam-auth-update, since the postinst just says: if [ $1 = remove ] ; then pam-auth-update --package --remove systemd fi Can you please verify? I don't think this is the case. Executing that command manually works just fine: --- pam.d/common-session2012-07-03 10:33:23.0 +0300 +++ /etc/pam.d/common-session 2012-07-03 11:11:34.438015939 +0300 @@ -23,7 +23,6 @@ # and here are more per-package modules (the Additional block) sessionrequiredpam_unix.so sessionoptionalpam_winbind.so -sessionoptionalpam_systemd.so sessionoptionalpam_ck_connector.so nox11 # end of pam-auth-update config The problem might be that the above script was not executed on removal? (ie. postrm or something) Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
Package: systemd Version: PAM adding faulty module: pam_systemd.so Severity: normal After packages removal I get these on syslog: | Jul 2 15:05:01 frost CRON[7633]: PAM unable to dlopen(pam_systemd.so): | /lib/security/pam_systemd.so: cannot open shared object file: No such | file or directory | Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so This is probably from this line in /etc/pam.d/common-session: | session optionalpam_systemd.so Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.6 ii initscripts 2.88dsf-28 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.13-34 ii libcap2 1:2.22-1.1 ii libcryptsetup4 2:1.4.3-2 ii libdbus-1-3 1.6.2-1 ii libkmod2 9-1 ii liblzma5 5.1.1alpha+20120614-1 ii libpam0g 1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-3 pn libsystemd-id128-0 none pn libsystemd-journal0 none ii libsystemd-login044-3 ii libudev0 175-3.1 ii libwrap0 7.6.q-23 ii udev 175-3.1 ii util-linux 2.20.1-5.1 Versions of packages systemd recommends: pn libpam-systemd none Versions of packages systemd suggests: ii python2.7.3-1 ii python-cairo 1.8.8-1+b2 ii python-dbus 1.1.1-1 pn systemd-gui none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
]] Teodor Package: systemd Version: PAM adding faulty module: pam_systemd.so Severity: normal After packages removal I get these on syslog: | Jul 2 15:05:01 frost CRON[7633]: PAM unable to dlopen(pam_systemd.so): | /lib/security/pam_systemd.so: cannot open shared object file: No such | file or directory | Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so This is probably from this line in /etc/pam.d/common-session: | session optionalpam_systemd.so I suspect you have told pam that you want to manage common-session by hand, else this is a bug in pam-auth-update, since the postinst just says: if [ $1 = remove ] ; then pam-auth-update --package --remove systemd fi Can you please verify? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679928: systemd: PAM adding faulty module: pam_systemd.so
On 02.07.2012 17:39, Tollef Fog Heen wrote: ]] Teodor Package: systemd Version: PAM adding faulty module: pam_systemd.so Severity: normal After packages removal I get these on syslog: | Jul 2 15:05:01 frost CRON[7633]: PAM unable to dlopen(pam_systemd.so): | /lib/security/pam_systemd.so: cannot open shared object file: No such | file or directory | Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so This is probably from this line in /etc/pam.d/common-session: | sessionoptionalpam_systemd.so I suspect you have told pam that you want to manage common-session by hand, else this is a bug in pam-auth-update, since the postinst just says: if [ $1 = remove ] ; then pam-auth-update --package --remove systemd fi Right, the issue is, that we switched to multiarch paths in 44-3. I think pam-auth-update should handle that correctly, i.e. update the paths in the pam configuration even if the pam-configs snippet hasn't changed. Steve, can you confirm that this should work? Is there an easy way to check if the pam configuration is managed manually and not by pam-auth-update? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
