Actively blocking fixes
Actively blocking fixes
Posted Nov 12, 2019 14:14 UTC (Tue) by kilobyte (subscriber, #108024)In reply to: Actively blocking fixes by bigon
Parent article: Debian reconsiders init-system diversity
Posted Nov 12, 2019 14:34 UTC (Tue)
by bigon (subscriber, #57617)
[Link] (4 responses)
Posted Nov 12, 2019 18:04 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (3 responses)
elogind and systemd do their cgroups layout in a completely different way; teaching one library / daemon to interpret / layout these data in a way that the other can read it is not going to happen. Elogind isn't going to implement systemd's cgroups features, systemd cannot use elogind's layout even if it wanted to because it doesn't support its feature set, neither library reads the other's data, and AFAIK nobody is doing any work to implement any of that.
Simply put, these two implementations cannot co-exist. libelogind can be used as a libsystemd stub but this will only work on a system running elogind.
The only way to get this to work in some stable kind of way (that I can see, anyway) would be a stub init that checks which real init should run, re-links the libsystemd0 symlink to point to either libsystemd0.whatever-version.so or libelogind.some-other-version.so, and execs the real init. Good luck doing that if [/usr]/lib should happen to be readonly. Oh yes, you'd also need to prevent ldconfig to overwrite the link, prevent dpkg to remove the "wrong" library if the "wrong" init is running, and probably some other problems I haven't thought of.
Summary: it's time to throw in the towel. Just declare systemd to be *the* supported init and be done with this mess. Anybody who still wants to run current Debian on non-current-Linux kernels would need to do some sort of fork, their problem (unfortunately!).
The amount of effort to accommodate non-systemd Debian machines has been staggering, but IMHO we've learned that it's too much effort for too little gain to be sustainable.
Posted Nov 13, 2019 7:13 UTC (Wed)
by zuki (subscriber, #41808)
[Link]
My conclusion is similar to the debian release team: there is no sane way to try to substitute libsystemd that would not break programs linking to it. Trying to do it live on a running system is madness. That library implements dbus and device queries and logging and an event loop, and putting in stubs is never gonna fly.
On the other hand, the original design to keep libsystemd, but replace the part behind the dbus boundary, i.e. logind with elogind, will not work either, because various libsystemd functions look at the cgroup layout.
The only solution that would IMHO work would be to make elogind use compatible layout of cgroup paths. This sounds complicated, but the systemd cgroup layout is simple and almost stable. Then libsystemd0 and elogind packages could be installed in parallel at any time, and they would both work. Using an incompatible layout would be OK if this was a completely independent project, but for a purported drop-in replacement, that is a gratuitous and deal-breaking incompatibility.
(In the infrequent scenario that systemd introduces a cgroup layout change, elogind would need to be adjusted. But Debian doesn't need to allow any version of systemd to work with any version of elogind, so it could have elogind declare Conflicts:systemd>nnn, until it is known that nnn+1 is still compatible or elogind is adjusted.)
People keep bringing up that when systemd was being introduced it was parallel installable on existing systems and could be turned on and off by setting init= kernel command line. That design choice made the initial introduction vastly easier. Too bad that the elogind people didn't go for the same thing.
(systemd developer here)
Posted Nov 13, 2019 17:20 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
I think I miss something really important here: you have to call mount once to bind-mount either libsystemd0.whatever-version.so or libelogind.some-other-version.so on top of libsystemdo.so... and that kinda implies root privileges... but PID1 always have them so... what's the problem?
Posted Nov 13, 2019 21:13 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Posted Nov 16, 2019 10:48 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
Would you mind providing some nontrivial examples of such functionality?
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
The only way to get this to work in some stable kind of way (that I can see, anyway) would be a stub init that checks which real init should run, re-links the libsystemd0 symlink to point to either libsystemd0.whatever-version.so or libelogind.some-other-version.so, and execs the real init. Good luck doing that if [/usr]/lib should happen to be readonly.
Actively blocking fixes
Actively blocking fixes