Summary: | commit 7708588119 broke logind DBus API | ||
---|---|---|---|
Product: | systemd | Reporter: | Michael Stapelberg <michael+freedesktop> |
Component: | general | Assignee: | 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
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.