Bug#727708: init system other points, and conclusion
Anthony Towns <aj@erisian.com.au> writes:
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?
My personal answer to this is that I truly don't know.
On one hand, we have four different init systems in Debian right now, plus
a fifth in experimental, and several of them have been in Debian for a
number of years. So clearly it's currently possible to have multiple,
working init systems. At least three of them (upstart, systemd, and
sysvinit) work reliably well in Debian right now. Some, although not very
many, packages have been converted to support upstart, systemd, or both
already.
On the other hand, much of why those init systems work is that we have the
lowest-common-denominator of init scripts in all packages. I suspect,
although am not sure, that a noticable amount of the long-tail software in
Debian will only work with the default init system. In any case where the
packager primarily cares about getting the software into Debian, not about
broader Debian project goals for the sake of doing things for Debian, I'm
not sure there's going to be much incentive to add support for the other
init systems, and I'm not sure there's going to be the resources to submit
them as patches.
Left to itself, I think the best case that we'll get for support for
alternative init systems will be at the level of our manpage coverage: we
never achieve it, but we don't do a horrible job. It's not clear to me
that would be a bad outcome. I think with a concerted effort on the part
of porters (most likely the non-Linux porters), we could do better than
that for one alternative init system, but it would involve a lot of
pestering people, which is generally not that fun and rather demotivating.
I think we have a substantially higher chance of effectively supporting
multiple init systems if none of them are sysvinit, because init scripts
are awful from a package maintainer's perspective.
But all of this is pure speculation.
I really hate making people unhappy, and I really hate seeing people's
work left behind, so I love the vision of a world in which we can actually
support a multitude of init systems. But I'm not sure how realistic it is
to expect enough package maintainers to care.
Personally, as much as time permits, I intend to support all init systems
that anyone in Debian is interested in, at least to the extent of
providing untested configurations for those init systems. I don't know if
I'll be able to follow through on that. Certainly, for simple daemons, I
can throw something together and be pretty sure it will work even though I
didn't test it. The real test will be supporting something like
openafs-client on an init system that I don't use. I would like to do
that, but I'm not sure that I will find the time in practice. But
certainly if someone else provides the patches, I'll apply them.
There are also some packages that have very complex initialization
requirements or that tie heavily into the early boot. Those are going to
be a harder challenge than the average daemon, since they're likely to
have specialized startup code that will have to be rewritten in multiple
ways for different init systems. For example, if we choose systemd, I
expect and hope that many of our hardest and most complex cases will
migrate to socket activation, which should make them far more robust and
much simpler to maintain. Once one has converted a complex and racy
startup to race-free and simple socket activation, I know it's going to be
hard to find the mental effort required to maintain the sysvinit scripts
or fix corner-case ordering bugs that socket activation just make
disappear.
> Forced to make a choice, should Debian go for smoother/tighter
> integration between apps, or more choice for users/sysadmins? I'd expect
> Debian to choose the latter; though Ubuntu, Red Hat and possibly Fedora
> might choose the former.
Well, here again, all of the above is the most attractive answer to me.
But my background, experience, and day-to-day work with Debian leads me to
choose an option that isn't on that list: more power, simpler
configuration, simpler management, and more directly useful features for
sysadmins. A world in which all services provided by Debian are started
with socket activation via configuration with a simple local override
mechanism is hugely attractive from an enterprise systems administration
perspective.
Socket activation is, I think, the biggest place where less capable init
systems are in danger of getting left behind. Once you have that feature
available, it solves so many problems that it's annoying to have to work
without it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: