In http://bugs.debian.org/717403 we recently noticed that libpam-systemd 204 cannot talk to systemd 44. I tracked this down to this commit, which introduced a new reply element: commit 770858811930c0658b189d980159ea1ac5663467 Author: Lennart Poettering <lennart@poettering.net> Date: Tue Oct 16 19:21:21 2012 +0200 logind: only release logind session from the PAM module if the same module instance actually created it I am not 100% sure if this reply is covered by http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ Could you clarify how updates from 44 to 204 are supposed to work? Do we _need_ to restart systemd-logind or could you fix libpam-systemd to work with older versions of systemd-logind, albeit not perfectly (it sounds like the commit is a bugfix)? Thanks.
CreateSession never was part of the promise really, and that's kinda documented: http://www.freedesktop.org/wiki/Software/systemd/logind/ Packages need to make sure that logind and pam_systemd is always updated/restarted in sync. CreateSession() is an internal API between the two, and it's parameters are undocumented and subject to change. Note that the update 44 → 205 probably requires a reboot anyway, as the cgroup tree changed substantially, and the old versions did not serialize the cgroup information.
(In reply to comment #1) > Note that the update 44 → 205 probably requires a reboot anyway, as the > cgroup tree changed substantially, and the old versions did not serialize > the cgroup information. Does that imply that 44 → 204 should be fine without a reboot? Also, could you please clarify what the implications are if we don’t reboot? I.e. will a systemd reexec not work for 204 → 205 (what about 44 → 205)? What stuff will break precisely? This is important for us to know since Debian does not have a good mechanism to force reboots on package upgrades.
203 is probably cutoff. Basically, the old versions didn't serialize the cgroup path during reexec, and we changed the layout of the cgroup tree quite a bit. The new code will hence try to use different paths than what the old version set up. And confusion will ensue. "systemctl status" will show you incorrect process lists, "systemctl stop" doesn't work anymore, systemd itself might consider services stopped that actually are running and suchlike. We nowdays do serialize the cgroup path, so this won't happen again.
(In reply to comment #3) > 203 is probably cutoff. 203? Should that say 205, or is it really 203? > Basically, the old versions didn't serialize the cgroup path during reexec, > and we changed the layout of the cgroup tree quite a bit. The new code will > hence try to use different paths than what the old version set up. And > confusion will ensue. "systemctl status" will show you incorrect process > lists, "systemctl stop" doesn't work anymore, systemd itself might consider > services stopped that actually are running and suchlike. > > We nowdays do serialize the cgroup path, so this won't happen again. So I gather from that: for updates from 205 to future versions, reboots will not be required due to cgroup path serialization.
(In reply to comment #4) > (In reply to comment #3) > > 203 is probably cutoff. > 203? Should that say 205, or is it really 203? > > > Basically, the old versions didn't serialize the cgroup path during reexec, > > and we changed the layout of the cgroup tree quite a bit. The new code will > > hence try to use different paths than what the old version set up. And > > confusion will ensue. "systemctl status" will show you incorrect process > > lists, "systemctl stop" doesn't work anymore, systemd itself might consider > > services stopped that actually are running and suchlike. > > > > We nowdays do serialize the cgroup path, so this won't happen again. > > So I gather from that: for updates from 205 to future versions, reboots will > not be required due to cgroup path serialization. Well, I don't really want to give that guarantee. The cgroup stuff we have now will fix that side of the upgrade story, but there might be other things coming up. Note that the reexec stuff is really primarily useful for smaller bugfix updates. Doing huge version changes is nothing this can or should cover. We cannot make guarantees really that this will always work. I mean, online updates are really broken anyway, and the larger the delta becomes the bigger the risk becomes. Doing arbitrary intra-version upgrades is something we don't test for, that one *cannot* really test due to the exploding test matrix of combinations...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.