On 2020-01-03 at 17:43, 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 - 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. 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. > 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. That does ease my mind about this somewhat, then. It also leaves me confused about how these daemons were getting started back when I was experimenting with this, to provide the side effects which I (half-)remember seeing, since I definitely wasn't running systemd as the init system; it also appears to leave systemd-the-package as much less useful to install without systemd-sysv. But my confusion about the past should not impede us acting in the present with regard to the future. (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, and before I wound up giving up and removing it.) >> 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? No - at the point when I was experimenting with this, elogind did not appear to have been packaged for Debian, and may (for all I know) not even have been written yet. >> 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! No, but if it would help resolve concerns (including my own) and potentially help clear the way for things to move forward, I'd be happier with it done - and if I can make myself happy, why shouldn't I? ^_^ >> (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. If you're right that installing systemd-the-package doesn't have the side effects that I thought I remembered it having, then I agree, this is probably not worth the trouble. I do still think that splitting it according to dependencies would be the theoretical ideal, but that can easily be outweighed by the added maintenance burden as long as there's no practical downside to having them all together in one package. (Splitting them would make it easier to provide reimplementations of one tool or another, without needing to either provide them all or conflict with systemd-the-package, but until now that's been largely theoretical and I think it's still not clear that there aren't better solutions to that problem.) > (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.) Yeah, AFAICT this is / would be orthogonal to the libelogind/libsystemd0 dependency issue. Thanks for the discussion! -- 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