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 - including both > systemd itself, and systemd-logind - being set up to run automatically > in the correct contexts (whether by scripted invocation set up by a > package, or by socket activation, or by some other means), in such a way > that they will generally wind up running even on a computer where > systemd-the-daemon is not the init system. I'm currently digging through > the result of 'apt-get source systemd', and I haven't yet managed to > either confirm or refute this with certainty.
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. This may be a concern in some future in which there are multiple init systems that interpret and act on systemd units, but this is not yet the case. That will be an integration worry that we'll have to tackle should that be the case in the future, but I don't think it's a concern right now. > Again if I recall correctly, there were some behaviors which arose from > having logind running in a non-systemd-as-init-system environment which > the maintainers did not consider something which they would need to fix > but which I found undesirable. Possibly you're thinking of the problem that Sam pointed out, which is that the systemd package depends on libsystemd0 which currently effectively conflicts with elogind, and therefore you can't install elogind and the systemd package simultaneously? If so, that indeed is true but is a problem that probably has to be fixed anyway, regardless of the current discussion, for elogind to be easily usable in Debian. This is a problem with package dependencies, though. Installing the systemd package should not cause systemd-logind to run. It is started via /lib/systemd/system/systemd-logind.service, which will be ignored unless systemd is running as PID 1. I would welcome corrections of I'm wrong, though! > I don't want to "risk" (in quotation marks because there may not be > much, if any, actual risk involved) my primary system on testing this, > and right now I don't have any spare systems or a working virtualization > environment (because I haven't been able to get libvirt, as packaged for > Debian, to work properly in a non-systemd environment) to use for > testing, so I'm not in a position to do that test myself. I do have a > functioning virtualization environment at my workplace, so if downtime > permits over the next week or three, I may be able to do that there. Totally understood, and obviously you're under no obligation to do the testing! > (Personally, I'd argue that splitting the various daemons and non-daemon > tools out into packages according to which ones depend on which others > makes sense purely from a "granularity of dependencies" perspective, but > it's been clear for a long time that that argument is a nonstarter with > the systemd maintainers.) The systemd maintainers do split out some binaries, but I don't think creating 20-odd packages for each individual small service (systemd has a general model of breaking the boot up into small, simple binaries that do a single thing) is necessarily an improvement. My understanding of the preference of the systemd maintainers is to not split the package except where there's a clear benefit (in terms of dependency structure or some other problem) that outweighs the ongoing cost of maintaining more individual packages. Here, if the systemd package works the way that I believe that it does, I don't think splitting will change anything other than saving a small amount of disk space on non-systemd systems. (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.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
