Hide Forgot
Description of problem: After upgrade to systemd 31 or 32 su became nonfunctional. Stderr message: su: cannot not open session: Cannot make/remove an entry for the specified session log message: pam_systemd(su:session): Failed to parse message: Message has only 3 arguments, but more were expected Version-Release number of selected component (if applicable): systemd-31,32 pam-1.1.4-3 coreutils-8.12-3 How reproducible: Always Steps to Reproduce: 1. upgrade to systemd >= 31 2. su - +root password from ordinary user or su from root Actual results: su fails with error. Expected results: su works Additional info: Console root login works. But if upgraded remotely, OS may loose you control - if not enough sudo entries exists. So - high severity.
Tested systemd 33 - same result. Fallback to 30 - all fine.
If you do "systemctl restart systemd-logind.service", do things work then?
The same result. It seems to be a change in protocol used by PAM: pam_systemd(su:session): Failed to parse message: Message has only 3 arguments, but more were expected
It's an interface change of the D-Bus iface of logind in an older version to a newer version. Normally this should go away if you restart systemd-logind.service, which more recent systemd packages do automatically on upgrade. If this doesn't happen for you for some reason an old pam_systemd instance sticks around. If you reboot does this go away?
After every systemd update or rollback I do reboot. Tested with systemd-34 - same result. Added some debug pam_warn in PAM system-auth. Here some logs: authpriv.notice<85>: Aug 29 19:10:24 atu [su:]< pam_warn(su-l:auth): function=[pam_sm_authenticate] service=[su-l] terminal=[pts/2] user=[root] ruser=[atu] rhost=[<unknown>]> authpriv.notice<85>: Aug 29 19:10:27 atu [su:]< pam_warn(su-l:setcred): function=[pam_sm_setcred] service=[su-l] terminal=[pts/2] user=[root] ruser=[atu] rhost=[<unknown>]> authpriv.err<83>: Aug 29 19:10:27 atu [su:]< pam_systemd(su-l:session): Failed to parse message: Message has only 3 arguments, but more were expected> authpriv.info<86>: Aug 29 19:10:27 atu [su:]< pam_unix(su-l:session): session opened for user root by atu(uid=1000)> authpriv.notice<85>: Aug 29 19:10:27 atu [su:]< pam_warn(su-l:setcred): function=[pam_sm_setcred] service=[su-l] terminal=[pts/2] user=[root] ruser=[atu] rhost=[<unknown>]>
Maybe you are using a mixed 32bit/64bit setup where the PAM module got updated in the logind service didn't or something like this? Did you every compile systemd yourself?
32-bit only setup. Most of packages taken from rawhide and rebuild. systemd-34 tested both binary from rawhide and self-made - no difference.
Created attachment 520869 [details] log of dbus-monitor --system: bad case (systemd-34) I made a 2 dbus-monitor logs: good1 - systemd-30, bad - systemd-34 No visual difference. strings 1-23 and tail - switching from tty4 (root) to tty2 (atu=1000) and back.
Created attachment 520870 [details] log of dbus-monitor --system: good case (systemd-30)
rawhide? Please run f16 proper and use the official packages. I am very sure you are for some reason running incompatible versions of pam_systemd and logind, and that's probaby due to the fact you built the package yourself and ended up with a partial upgrade. But this is the wrong place to file bugs about self-built packages, this bug tracker is for fedora packages (and rhel, ...). Please reopen if you can reproduce this issue with a standard f16 system with no left-overs of self-built packages. Thanks.
Found a source of this bug. Since historic times is was a manualy added string to /etc/pam.d/system-auth-ac: session required pam_systemd.so It was added by hand as authconfig don't do this at that time. After switching to -session optional pam_systemd.so all works. P.S. I have some doubts - at may be a now masked bug, for example - logind may use different number of params in login and su. I will not reopen - all works.