[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [draft] Draft text on Init Systems GR

Hello Wouter,

Wouter Verhelst [2019-11-09 10:32 +0200]:
> > Choice 1: Affirm Init Diversity
> > 
> > Being able to run Debian systems with init systems other than systemd
> > continues to be something that the project values.  With one
> > exception, the Debian Project affirms the current policy on init
> > scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
> > should include init scripts to start services that are included.
> > Policy notes that early boot services like those started from
> > /etc/rcS.d may be tied closely to the init system in use.
> I don't see why this is relevant in the current discussion.
> My nbd-client package is one that is relevant here; it has a systemd
> unit, and an rcS init script (which is then ignored by systemd). If this
> choice wins, then init scripts remain mandatory. If you provide an rcS
> init script, then systemd units are also mandatory.

IMHO early-boot services in rcS.d are one of the most important aspects of this
entire discussion. Late boot services are generally easy, as the vast majority
have simple dependencies and simple startup logic in the sense of how deeply
they need to interact with the guts of the OS. Ignoring systemd features like
privilege reduction/isolation/robustness, a systemd unit and a SysV script that
uses /lib/init/init-d-script have roughly the same complexity. They are
reasonably easy to test on both a systemd and a SysV init system, and it's the
right thing to let them be maintained by the individual package maintainers.

But this picture is entirely different in early boot (rcS.d, or
sysinit.target): these have complex, brittle, and dynamic dependencies, are
hardware/install type/configuration dependent, and require an integrative
cross-package design, development, and maintenance.  This is the part where
SysV init scripts and distributed maintenance are desperately bad, and why a
lot of configurations had been so buggy or impossible for many years. They
suffer from imperative shell script hell and not enough machine
readability/introspectability/uniformity to reason about or validate them.

For these a distributed maintenance approach has been shown to not work well;
integrating NetworkManager, LUKS, NFS, LVM, RAID, dynamic partition type
detection, udev, X.org/wayland/login managers etc. needs to be a primary
responsibility of the team that maintains the init system itself [1].  These
need comprehensive system integration tests [2] with lots of different

This is the one thing in that GR that I have a strong opinion on (backed by
doing *two* init system migrations in my life): Choice 1 is a non-starter if it
mandates distributed SysV init script maintenance for early-boot services. If
these are exept, and maintained/QAed by the corresponding init system, then
Choice 1 is very sensible and practical.

I wish that the GR text could expand on that a little bit, but I do appreciate
that this quickly gets into the trenches of deep technical details. For now I
interpret the last sentence as a sufficient exception (avoiding the word
"loophole") for that scenario.

> So this is not an exception to the rule? It just means you have more
> work to do.

What do you mean by "more work to do"? I. e. what and who?



[1] That of course doesn't mean that the package maintainer doesn't have a say
in that -- they absolutely do. But to a large degree they need to trust and
defer to the maintainers of the init system.

[2] autopkgtests can also do that -- I wish we had had what we have today in
the upstart/early systemd times!

Reply to: