Re: [arch-general] pam upgrade and systemd
arch-general-request@archlinux.org schreef op 2015-05-19 14:00:
Anyone have a system they haven't upgraded in ~24hrs to give it a further test, see if logins are broken after the pam upgrade?
-te
I've had similar issues, except it broke systemctl --user functionality. systemctl daemon-reexec didn't work. For now I've downgraded to Pam 1.1.9. Can you try rebuilding systemd with ABS (perhaps it only needs to be linked against the new PAM version) Alad
Sat, 23 May 2015 13:39:00 +0200 Alad Wenter <alad@archlinux.info>:
arch-general-request@archlinux.org schreef op 2015-05-19 14:00:
Anyone have a system they haven't upgraded in ~24hrs to give it a further test, see if logins are broken after the pam upgrade?
-te
I've had similar issues, except it broke systemctl --user functionality. systemctl daemon-reexec didn't work. For now I've downgraded to Pam 1.1.9.
Can you try rebuilding systemd with ABS (perhaps it only needs to be linked against the new PAM version)
Alad
This isn't about downgrading or rebuilding, but rather about sub-par information. If you're upgrading a bunch of packages (your usual -Syu) with 'pam' being one of many and it's not echoing any hint or warning about a soname change, well, duh. PAM is such an essential library that I wouldn't bother with identifying which services and programs need to be reloaded, but rather simply reboot. I overlooked it too, until I discovered I couldn't unlock xscreensaver. --byte
On Sat, May 23, 2015 at 6:59 AM, Jens Adam <jra@byte.cx> wrote:
information. If you're upgrading a bunch of packages (your usual -Syu) with 'pam' being one of many and it's not echoing any hint or warning about a soname change, well, duh. PAM is such an essential library
...coupled with the fact I work (real job) on RHEL/CentOS/Debian/Ubuntu servers where this doesn't happen often due to vendor design - glibc and pam upgrades tend to never be a problem in these. I come back to using my laptops running Arch and have to switch mental gears where latest-and-greatest upgrades break a running system and reboots are the norm, something I just tend to forget as a rolling release. I did a little debugging in VirtualBox and could get systemd to reload it (systemctl daemon-reexec, daemon-reload didn't release it) but more lsof shows everything from lightdm to cupsd to gdbus has the old libpam.so DEL in memory, so while restarting everything would work we just reboot for convenience. Is what it is. It would be kinda cool if we had a fundamental design from the ground up where a library upgrade could signal a system-wide HUP to reload -- that would have to have been done years ago though to set the paradigm for all binaries to follow, no way we could retrofit the Linux ecosphere at this point and get all userspace to comply. Some distros have attempted to tackle this with scripts[1][2] of various sorts, but none of it bulletproof or distro agnostic. -te [1] http://yum.baseurl.org/gitweb?p=yum-utils.git;a=blob_plain;f=needs-restartin... [2] https://anonscm.debian.org/cgit/collab-maint/debian-goodies.git/tree/checkre...
Sat, 23 May 2015 13:39:00 +0200
This isn't about downgrading or rebuilding, but rather about sub-par information. If you're upgrading a bunch of packages (your usual -Syu) with 'pam' being one of many and it's not echoing any hint or warning about a soname change, well, duh. PAM is such an essential library that I wouldn't bother with identifying which services and programs need to be reloaded, but rather simply reboot. I overlooked it too, until I discovered I couldn't unlock xscreensaver.
--byte
You're right; I've read the error message wrong. Sorry for the noise. Alad
participants (3)
-
Alad Wenter
-
Jens Adam
-
Troy Engel