Sam, Many thanks for this.
On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote: Mark> I have tried the approach suggested by Laurent of using Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs Mark> to function correctly. > What trouble did you run into? That sd-login(3) APIs failed to match pids to the current session and so policykit authorisation failed. > So, I think I understand Julian's issues better after trying to write my > bits from the DPL mail. You have explained Julian's position and concerns far more clearly than has ever been the case directly to me. > You haven't really tried to address them at all. Hmmm. I think I have in line with the clarity with which they have been expressed. But let's move on. > His issue is that we have a long history of trouble with apt and c/r/p > being used this deep in the dependency chain. > So, he's arguing that you have a high bar (possibly infinitely high) for > using that approach. > > Ultimately he wants you to produce a solution where multiple init > systems can be coinstalled and where you don't need a conflicts. OK. But elogind is not an init. sysvinit-core and systemd are coinstallable, but not sysvinit-core and systemd-sysv. Do you mean he wants elogind and systemd to be coninstallable? > I think you've explored some of that design space and have a feel for > why some of that is unattractive. > As an example, if you have systemd installed, it might be running. The > combination of systemd running and libelogind0 being the systemd library > is unfortunate. Trying to boot systemd in that configuration (using > libelogind0) would presumably be quite fatal. Yes and this is currently prevented because both elogind and libelogind0 conflict with systemd. > So, the next question is why libelogind0 needs to exist. That is why > can't you just use libsystemd0 with elogind? > What I've heard so far is "It doesn't work." This was asked of elogind upstream this question almost a year ago: https://github.com/elogind/elogind/issues/97 In particular Yamakazure replied "What I can guarantee is, that if you link something against libsystemd, and then use elogind, that "something" will not work, as the inner workings of libsystemd are quite different. So keeping libsystemd around is no option. But if libsystemd is gone and simply replaced by libelogind, it might work." And we have since demonstrated that once the libelogind0 exposes the same ABI as libsystemd0 so it can be used as a direct replacement, it does work. A couple of days ago I built elogind without libelogind0 and installed it on a system with sysvinit-core and libsystemd0. Applications using the sd-login(3) API, most notably policykit-1 failed to associate pids and sessions and so all policykit-based authentication failed. > Why doesn't it work? How hard would it be to make it work? I am not completely sure. But I think it is because elogind and systemd-login store information in /sys/fs/cgroup/ differently because elogind does not have or need many of the features of systemd. Currently you need a matched pair, either systemd/libsystemd0 or elogind/libelogind0 for successful operation. elogind is never going to have all the features of systemd. That would be pointless. If you want or require all of those features, just use systemd. > Would that be better for Debian than using c/r/p? > And the answer to some of these might be "we don't know and we don't > have anyone who can find out." > That is a fine answer to give, although it might also be fine for the > release team to say that they want that analysis before committing to > something dangerous like c/r/p libsystemd0. > > But even if we understand why libelogind0 is needed, then why do we need > c/r/p libsystemd0? > Could we do something with dpkg-divert? Would that be better? It might possibly work. I will try it out. But, playing devil's advocate, I don't really see the difference: you will still be replacing libsystemd.so with libelogind.so. The only difference is where it happens -- in the package or via dpkg-divert. > If we are going to use c/r/p libsystemd0, is there some way we can limit > the potential damage to people who have positively indicated that they > want to run a non-default init system? > One of the concerns is what happens if apt decides somehow that it wants > to install libelogind0 when you don't expect it. I have to admit I don't understand this fear. libsystemd0 is just a way of talking to a running systemd process. If systemd is not running and PID 1 libsystemd0 APIs generally return non fatal errors. So by running a non-default init, libsystemd0 is only there to satisfy dynamically loaded symbols at runtime. Otherwise it is basically non functional. libelogind0 is the same if elogind isn't running. So the scenarios I can see are 1) systemd PID 1 with libsystemd0 2) alternative init with libsystemd0 3) alternative init with libelogind0 4) no init (container, chroot) with libsystemd0 5) no init (container, chroot) with libelogind0 6) alternative init with elgoind and libelogind0 In 2), 3), 4) and 5) libsystemd0 and libelogind0 are non-functional beyond satisfying the runtime linker. Only in 1) and 6) do the library APIs return anything useful. Mark
