[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Uoti Urpala]

On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> My question really isn't "why are the Debian dependencies the way they are".  I understand that.  I was trying to highlight the strange situation of a desktop application requiring a particular init system.  I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd.  To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate.  Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains.

"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.

AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.


> I never thought much about my init system until recently.  I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases.  So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is).

The issue with "I should be able to stay with sysvinit because it worked
fine for me" is that keeping sysvinit working is COSTLY. The reason
sysvinit used to mostly work was not that it would have been a reliable
system - it mostly worked because people kept using a lot of effort to
work around and paper over various issues that kept popping up. And
there's no justification to keep up that effort for the minority who
wants to stay with sysvinit. So, you can keep running your old systems
unchanged if you want, but you shouldn't expect to be able to upgrade
them or install new software without switching to systemd.