On 2020-01-03 at 19:33, Simon McVittie wrote: > 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. I will certainly take your word for that. That it was a thing is an understanding I acquired over the course of reading previous mailing-list discussions (both contentious and otherwise), and in examining the idea more closely over the course of this conversation I've begun to notice some things that don't seem quite right about it anyway. > Socket activation is a systemd feature resembling inetd <snip> Thanks for the explanation. > 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. This sounds like the feature I was thinking of. I think I understood that the way this message got from the originating program to D-Bus (and thence to the service, once running) was by way of a socket which would / should be owned by that service, much as you describe for systemd's socket-activation feature, and that automatic "lazy" activation of the service by D-Bus in this way was therefore called D-Bus socket activation. This may itself be based on some confused understandings of some of the terms involved. If so, please don't feel obliged to spend your time explaining them; although I'd be glad to learn, I'm sure you have more productive things to do. <snip> > 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. That clarifies much. Thank you for the explanation! >> 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.). All of these (except the system-image-under-construction) are part of what I had in mind when saying "much less useful" rather than "useless". Thanks for listing them, though! >> (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. That sounds right, yes. I was surprised to find out just how much that I'd thought would grow dependencies on systemd-logind, and hence become unusable without the behavior changes which come along with logind, did not actually do so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature