Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
On 2021-09-14 08:56, Simon McVittie wrote: > On Mon, 13 Sep 2021 at 22:59:32 +0200, Aurelien Jarno wrote: > > - running the operation on a non-existing user, but as loginctl does a > > check that the user exists, it has to be done directly with the dbus > > API, for instance "gdbus call --system --dest org.freedesktop.login1 > > --object-path /org/freedesktop/login1 --method > > org.freedesktop.login1.Manager.SetUserLinger 12345678 true true" > > > > The latest is more a bit more complex to do (especially that > > libglib2.0-bin is not necessarily installed on the system), but has the > > advantage of exercising all configured NSS modules. > > systemd happens to have its own D-Bus implementation sd-bus (a competitor > to libdbus and GLib's GDBus) for which it provides busctl(1), an > equivalent of gdbus(1) and dbus-send(1). So this could be written as: > > busctl call --system org.freedesktop.login1 /org/freedesktop/login1 \ > org.freedesktop.login1.Manager SetUserLinger ubb $uid true true > > which does not have dependencies outside systemd.deb. Thanks a lot for the help here, as my knowledge with systemd is relatively limited. That seems to work fine when executed just before the libc6 upgrade in the script I use to trigger the upgrade at boot time. I'll try to insert all pieces into libc6.preinst and see if that still works. > The nonexistent uid should probably be in one of the ranges reserved by > Policy §9.2.2: perhaps 4294967294 or (uint32_t) -2, which is reserved > as a representation of the anonymous NFS user? Yes, that is probably a good pick. I guess we should actually disable lingering (so ... ubb 4294967294 false false) to minimize the damages if this user exists anyway. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
On Mon, 13 Sep 2021 at 22:59:32 +0200, Aurelien Jarno wrote: > - running the operation on a non-existing user, but as loginctl does a > check that the user exists, it has to be done directly with the dbus > API, for instance "gdbus call --system --dest org.freedesktop.login1 > --object-path /org/freedesktop/login1 --method > org.freedesktop.login1.Manager.SetUserLinger 12345678 true true" > > The latest is more a bit more complex to do (especially that > libglib2.0-bin is not necessarily installed on the system), but has the > advantage of exercising all configured NSS modules. systemd happens to have its own D-Bus implementation sd-bus (a competitor to libdbus and GLib's GDBus) for which it provides busctl(1), an equivalent of gdbus(1) and dbus-send(1). So this could be written as: busctl call --system org.freedesktop.login1 /org/freedesktop/login1 \ org.freedesktop.login1.Manager SetUserLinger ubb $uid true true which does not have dependencies outside systemd.deb. The nonexistent uid should probably be in one of the ranges reserved by Policy §9.2.2: perhaps 4294967294 or (uint32_t) -2, which is reserved as a representation of the anonymous NFS user? smcv
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
Hi Michael, On 2021-09-13 19:13, Michael Biebl wrote: > Hi Aurelien, > > thanks for the bug report > > On Thu, 9 Sep 2021 18:48:42 +0200 Aurelien Jarno wrote: > > > One way to workaround the issue would be to force systemd-logind to do a > > NSS lookup, just like it it s already the case when a user log onto the > > system. > > Before the upgrade, I assume, i.e. in libc6.preinst? Yes, exactly. > Have you already tested this? If so, what did you use? > Should we construct something based on systemd-run maybe? Unfortunately it's not easy. loginctl is doing a lot of checks before calling systemd-logind, and systemd-logind is doing a lot of tests before doing a call to NSS functions. Most notably, it needs to be a real login associated with a seat, so faking a login is not possible. The only thing I have found is to ask systemd-logind to enable or disable lingering. To avoid actually changing the configuration, the two following options works: - running the operation on an existing user, but without the associated permission. For instance running "loginctl enable-linger root" as user nobody. - running the operation on a non-existing user, but as loginctl does a check that the user exists, it has to be done directly with the dbus API, for instance "gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.SetUserLinger 12345678 true true" The latest is more a bit more complex to do (especially that libglib2.0-bin is not necessarily installed on the system), but has the advantage of exercising all configured NSS modules. In any case we can probably check if the above trick is needed by running something like "grep -E 'libnss_(compat|db|files)' /proc/$(systemctl show --property MainPID --value systemd-logind.service)/maps" I haven't test the full pattern by including this in the preinst, but so far I have been running the above snippet before doing the upgrade, and I has worked. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
Hi Aurelien, thanks for the bug report On Thu, 9 Sep 2021 18:48:42 +0200 Aurelien Jarno wrote: > One way to workaround the issue would be to force systemd-logind to do a > NSS lookup, just like it it s already the case when a user log onto the > system. Before the upgrade, I assume, i.e. in libc6.preinst? Have you already tested this? If so, what did you use? Should we construct something based on systemd-run maybe? Michael signature.asc Description: This is a digitally signed message part
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
On 2021-09-09 18:26, Aurelien Jarno wrote: > Package: libc6 > Version: 2.32-1 > Severity: serious > X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > > The NSS modules provided by glibc 2.32 require new symbols, which are > therefore not provided by libc6 2.31. This is why we require restarting > daemons after the new libc6 is installed. > > systemd-logind is also using NSS modules, so it needs to be restarted. > Unfortunately that's not something possible without killing Xorg > sessions (see bug#919509). Not restarting systemd-logind means that it > is not able to load new NSS modules, howeveralready loaded modules are > still usable. One way to workaround the issue would be to force systemd-logind to do a NSS lookup, just like it it s already the case when a user log onto the system. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
Package: libc6 Version: 2.32-1 Severity: serious X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org The NSS modules provided by glibc 2.32 require new symbols, which are therefore not provided by libc6 2.31. This is why we require restarting daemons after the new libc6 is installed. systemd-logind is also using NSS modules, so it needs to be restarted. Unfortunately that's not something possible without killing Xorg sessions (see bug#919509). Not restarting systemd-logind means that it is not able to load new NSS modules, howeveralready loaded modules are still usable. One visible consequence is that on systems where no user sessions have been registered with systemd-logind, new sessions will fail to register after the libc6 upgrade with the following king of error: sshd[647]: pam_systemd(sshd:session): Failed to create session: No such process Not registering the session causes among other things XDG_RUNTIME_DIR to not be defined (or even created), causing autopkgtest failures: https://ci.debian.net/data/autopkgtest/testing/amd64/c/calibre/15138528/log.gz Here is a simpler way to reproduce the problem: - Schedule the libc6 upgrade from 2.31 to 2.32 (currently bookworm to sid) to happen on a system which hasn't seen any user login since it has been booted. For instance trigger it from /etc/rc.local. - Log onto the system (for instance through TTY or SSH), observe the error message in the logs and the absence of XDG_RUNTIME_DIR in the environment.
