Re: Integration with systemd
Russ Allbery wrote:
> One of the options that I find interesting is to enumerate a list of
> features in unit files that Debian supports, and require that any
> Debian init system be able to handle unit files with those features.
> This standardzes an *API* for both package maintainers and upstream
I sincerely hope that we never have to support multiple implementations
of the unit file format with varying levels of support for its
directives. The point of my mail was to propose acknowledging the end of
the lowest-common-denominator approach.
(Also, the surface area of systemd is far broader than just unit file
directives, and many of the directives exist to integrate with other
features.)
> It's similar to what we did for /bin/sh (although this is of course
> much more complicated).
With /bin/sh, we just required that *if* you write #!/bin/sh you only
use /bin/sh features. (And a non-bash /bin/sh already existed, as well
as an industry standard defining the required behavior of /bin/sh, which
pre-dated bash.)
Critically, people *always* had the option to write #!/bin/bash
if they actually used the features of bash.
> Of course, this approach is not viable if it turns out that too few people
> are interested in init system diversity sufficiently to do the reasonably
> substantial implementation work required to maintain a competing
> implementation of the systemd unit features we care about.
Part of the problem is that the people interested in sysvinit don't tend
to care about those features and often argue that others shouldn't care
either, and the people interested in those features don't tend to care
about sysvinit. It's difficult to motivate people to work on
alternatives for a system they already have and prefer.
That's leaving aside that a reimplementation of systemd's features will
tend towards becoming systemd, and we have one of those already. What is
the actual goal? As a limiting case to prove the point, suppose someone
patched systemd to support running as a PID other than 1, underneath
sysvinit, using mechanisms like prctl PR_SET_CHILD_SUBREAPER and cgroups
to let it act like init without being PID 1. (By comparison, that would
*not* be an especially hard problem.) Would that solve the problem of
"must run under sysvinit"? Something tells me that that solution would
not be considered acceptable by folks who want to keep running sysvinit.
There are additional unspoken constraints here.
It seems evident based on the history of such efforts that there is
*not* sufficient people/interest/motivation to reimplement the majority
of systemd features, let alone doing so in a way that meets the
additional constraints imposed on such solutions. That support isn't
going to materialize out of hope. What would it take for us to document
the situation and move forward, rather than assuming that it might
change?
Reply to: