On Fri, 03 Jan 2020 at 14:43:48 -0800, Russ Allbery wrote: > The Wanderer <wande...@fastmail.fm> writes: > > If I recall and understand correctly, installing systemd-the-package > > will result in at least some of the daemons therein [being run] > > This is the bit that I'm fairly sure is not the case. > > All of the native systemd facilities are started via systemd units. If > systemd is not running as PID 1, nothing is going to load or act on the > systemd units. Therefore, nothing will start those services.
The three cases where this might not hold are: * You have something that is specifically running one of systemd's various smaller daemons, like the way systemd-shim arranged for systemd-logind to run (and pretended to be the systemd "manager" - the actual init system - so that systemd-logind worked, at least partially). Now that systemd-shim has been removed, I don't think this case exists. * One of systemd's smaller daemons is designed to run even on non-systemd systems, and so has an LSB init script as well as a native systemd unit. I think the only one in this situation is udev, which used to be a separate source package before becoming part of the systemd source package, and is already in its own separate binary package so it can be installed or removed independently. * You install another init system that systematically runs systemd service units, either directly or by generating its own equivalent of service units: this would look a lot like the way systemd generates systemd services from LSB init scripts, but in reverse. I don't think this exists yet. If this happens, it will definitely need a mechanism to "mask" unsuitable units, such as those that are known to encode systemd assumptions, rely on systemd features that it doesn't implement, or have a better or more native way to work in the other init system - just like the way systemd "masks" LSB init scripts that have an equivalent systemd unit or are otherwise not suitable to be run under systemd, but in reverse. It will probably also need some more general rules or heuristics, like perhaps skipping early-boot systemd units (those with DefaultDependencies=no) because those are more likely to have systemd-specific behaviour and less likely to be compatible with other init systems. Again, this is the inverse of the way systemd's LSB init script compatibility layer in recent versions acts on /etc/rc[2-5].d (late boot) but ignores /etc/rcS.d (early boot). I suspect you'd find that all or nearly all of the units provided by the systemd binary package would be unsuitable to be run by the other init system, and would need to be either masked or excluded by a rule. > (Splitting doesn't avoid the library dependency problem that currently > causes problems with elogind, since I believe the programs in question > also depend on that shared library.) Actually... systemd has a public shared library with a stable API, libsystemd0, and a separate private shared library that is tightly coupled to the contents of the systemd package, libsystemd-shared-${version}.so. If I understand correctly, the systemd daemons and helper executables are mostly (all?) linked to the private library, and are not linked to the public library at all: the private library has its own copies of some of the same functions that are in libsystemd0's ABI, for example sd_uid_is_on_seat(). Certainly that seems to be true for -tmpfiles and -sysusers. (The practical effect is the same as if -tmpfiles and -sysusers were statically linked to the shared systemd code that they need, but the use of a private shared library makes them smaller than if that had been done.) If that's true in general, then the systemd binary package might not actually need to depend on libsystemd0 at all; or failing that, it might be feasible to split out -tmpfiles, -sysusers and possibly others into a systemd-bin package that contains the private library and those executables, and does not depend on libsystemd0. If that split took place, systemd would depend on systemd-bin (= ${binary:Version}). smcv