Am 09.03.19 um 15:00 schrieb Michael Biebl: > Am 09.03.19 um 14:10 schrieb Julien Leproust: >> Hi, >> >> I found the issue. >> >> When looking for /etc files not belonging to any package, I discovered >> that /etc/pam.d/common-* files are managed by pam-auth-update. >> >> Most pam profiles were enabled, except "Register user sessions in the >> systemd control group hierarchy", and just enabling it fixed the >> problem. The systemd user service and logind session are now correctly >> started and everything works fine (device permissions, pulseaudio, etc). >> >> The real issue becomes why this pam profile got disabled in the first >> place. > > libpam-systemd uses pam-auth-update as documented. > There is no code in the libpam-systemd package which disables/removes > pam_systemd.so. > > So either you have at some point modified /etc/pam.d/common-* yourself > or there is a bug in pam-auth-update. > > If I had to guess, the former is more likely.
Afaik, if at some point in the past you have modified /etc/pam.d/common-* manually and you then install libpam-systemd, pam-auth-update will preserve your local changes and not add pam_systemd.so. Are you absolutely sure, pam_systemd.so was enabled in the past and at some point suddenly removed from /etc/pam.d/common-session? Or is it more likely that pam_systemd.so was never enabled? If pam_systemd.so was suddenly disabled, can you pin this to a certain event, like files being restored from a backup? In case, there is not really something we can do about this in the libpam-systemd package. As said, it does not actively remove pam_systemd.so. What we might do is to include the contents of /etc/pam.d/common-session in the bug report (via a libpam-systemd bugscript) to make issues like this easier to spot in the future. 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
