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