Why a disabled feature that should just do nothing even if its pam module is loaded, infinitely loops on D-BUS access in its pam module?
Anyway, I reported it and it presumably got fixed. I wouldn't know, because systemd dev handling this didn't say a thing to me at all. Just closed the report after some seemingly not very related commits to what I saw in gdb.
I just dropped the pam module from config anyway, and I'm not willing to lose access to my cluster again just to try.
Not sure how distro fucked up in this case, when it's homed pam module going into infinite loop once in a while unpredictably blocking all processes that use pam naively, unless you mean that they fucked up by using systemd or pam at all.
Edit: lol, I read through systemd release notes and there's no mention of new huge systemd-homed pam module at all. But good I looked, they're moving pam config for systemd to /usr/lib/pam.d and systemd-home pam module is again enabled there. So I'll have to check again all my systems if it's really disabled after upgrade.
Anyway, I reported it and it presumably got fixed. I wouldn't know, because systemd dev handling this didn't say a thing to me at all. Just closed the report after some seemingly not very related commits to what I saw in gdb.
I just dropped the pam module from config anyway, and I'm not willing to lose access to my cluster again just to try.
Not sure how distro fucked up in this case, when it's homed pam module going into infinite loop once in a while unpredictably blocking all processes that use pam naively, unless you mean that they fucked up by using systemd or pam at all.
Edit: lol, I read through systemd release notes and there's no mention of new huge systemd-homed pam module at all. But good I looked, they're moving pam config for systemd to /usr/lib/pam.d and systemd-home pam module is again enabled there. So I'll have to check again all my systems if it's really disabled after upgrade.