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

[Simon McVittie <smcv@debian.org>]

On Fri, 03 Jan 2020 at 18:07:36 -0500, The Wanderer wrote:
> What I'm concerned about is dbus socket activation, or similar, leading
> to e.g. logind getting activated by logging in at the text console.
> 
> I thought I understood that socket activation via dbus was one of the
> features which didn't require systemd as PID-1 to function.

I think you're confused. I don't think "socket activation via dbus"
has ever been a thing that existed.

Socket activation is a systemd feature resembling inetd, where instead
of starting a daemon (let's say a web server) that listens on a port (let's
say TCP port 80), systemd starts listening on port 80 on behalf of the
web server, and doesn't actually run the web server itself yet. Later,
when a client connects to that socket, systemd starts the web server
and hands over the listening socket to it, the web server accepts the
client's connection and everything continues as usual.

Perhaps confusingly, on machines where systemd is pid 1, the dbus-daemon
is one of many services that makes use of socket activation: it
configures systemd to listen on the well-known AF_UNIX socket for the
system dbus-daemon, and hand over to the actual dbus-daemon the first
time there is a client. (The relevant files are dbus.socket and
dbus.service, if you're interested.)

D-Bus activation is a D-Bus feature where instead of starting a D-Bus
service (another sort of daemon) "eagerly" in case it might be needed,
the dbus-daemon starts that D-Bus service "lazily" the first time some
other program sends a message to it. dbus-daemon can either do this
directly as its own child process, which is portable to all reasonable
Unix platforms (this is called "traditional activation"); or on systemd
systems, if the D-Bus service definition includes the name of a systemd
unit, dbus-daemon can start it indirectly, by asking systemd to start
that unit (this is "systemd activation"). systemd activation is preferred
where supported, because systemd was designed to be a service manager,
whereas dbus-daemon is an IPC broker with some very basic service
management bolted onto the side.

Both of those lazy-loading mechanisms (socket activation and D-Bus
activation) let services start with greater parallelization and fewer
explicit dependencies, and they are particularly useful in situations
where service A can be configured in a way that makes it depend on
service B (but does not always), and service B can be configured in
a way that makes it depend on service A (but does not always). In a
traditional linearly-ordered boot process like sysv-rc, there would be no
correct order in which to start A and B, so Debian would have to choose
one configuration to allow, and deliberately break the other one (for
example if we chose to start A before B, then configuring A to depend on
B while configuring B to not depend on A can't work). With activation,
as long as you don't try to configure each of A and B to depend on the
other at the same time (which obviously can't work), either way round
works equally well.

Some of systemd's smaller daemons, like logind, are activatable D-Bus
services, so in principle they could be started by dbus-daemon via
traditional activation. However, the "program to execute" in the D-Bus
service definition is set to /bin/false, so they cannot actually be
activated successfully unless dbus-daemon was told to carry out systemd
activation, which only happens on systems where systemd is pid 1.

There has been a proposal to adjust the syntax of D-Bus service
definitions so that they can say "if systemd is pid 1, activate via
systemd unit foo.service, else behave as though this activatable
service didn't exist", rather than having to use Exec=/bin/false as a
workaround. I'll probably implement that at some point, and logind will
probably be one of the first services to use it.

> it also appears to leave systemd-the-package
> as much less useful to install without systemd-sysv

The systemd binary package is useful for systemd-tmpfiles,
systemd-sysusers, controlling a container or
system-image-under-construction that *does* boot with systemd
(systemctl --root=/mnt/otherdevice), or booting with init=/bin/systemd
as a non-default option. Other than that, you're correct to say that
systemd-sysv is the package that actually provides services (pid 1,
logind, journald, etc.).

> (I wonder if maybe I had libpam-systemd installed at the time, and that
> was what was triggering logind to run? It's possible that this may have
> been back before that couldn't be installed without systemd-sysv

I suspect you were using libpam-systemd in combination with systemd-shim.
The entire point of systemd-shim was that it would run systemd-logind
on systems that did not have systemd as pid 1. This turned out to be
unsupportable and it was removed.

    smcv