Bug 67131

Summary: commit 7708588119 broke logind DBus API
Product: systemd Reporter: Michael Stapelberg <michael+freedesktop>
Component: generalAssignee: systemd-bugs
Status: RESOLVED NOTABUG QA Contact: systemd-bugs
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Michael Stapelberg 2013-07-21 11:09:13 UTC
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.
Comment 1 Lennart Poettering 2013-07-21 22:49:27 UTC
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.
Comment 2 Michael Stapelberg 2013-07-23 15:29:41 UTC
(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.
Comment 3 Lennart Poettering 2013-07-24 15:45:29 UTC
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.
Comment 4 Michael Stapelberg 2013-07-24 16:56:53 UTC
(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.
Comment 5 Lennart Poettering 2013-07-24 17:12:04 UTC
(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.