Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Simon McVittie <smcv@debian.org>]

On Fri, 03 Jan 2020 at 14:43:48 -0800, Russ Allbery wrote:
> The Wanderer <wanderer@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