Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter <sjr@debian.org>]

Hi,

On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:

> As a lot of the conflict between sysvinit and systemd was about the
> philosophy.

I wouldn't say "philosophy". These are different technical designs, and
each design has certain capabilities and limitations. It is not possible to
build a design that has the strengths of both but none of the weaknesses,
because you'd have to solve the halting problem for that.

For a desktop environment it makes a lot of sense to have a microservice
architecture such as the one that systemd provides. Typical desktop use
cases are "connect these Bluetooth headphones" and "allow the user on the
local console to select an active network card and configure settings".

The network device configuration case is a simple policy decision. The
logged-in user is the owner of the system and also the only stakeholder, so
in this case it makes sense to provide an interface that allows a
non-privileged user to perform a privileged action, limited by the
expressiveness of the interface. The network configuration API does not
allow setting up a complex routing table with multiple weighted
alternatives, because that is not part of the use case, and that is fine.

The bluetooth headset use case goes a bit beyond policy. There is still a
system-wide element (hardware access only for the local user), but most of
the software stack involved lives in userspace now and is orchestrated as
microservices, including a mechanism to topple the entire stack on error.
That is a sensible design choice -- if the user walks out of range with
their headset, there is no sensible way to provide audio service, and the
existing kernel audio APIs do not have an appropriate signaling mechanism.

For servers, the benefit is rather limited. There is no local user who
makes system-wide policy decisions, and hardware is not changing
dynamically either. The actual services provided are either implemented as
daemons (i.e. not microservices), or proper microservices run inside a
site-wide microservice framework such as Docker+Kubernetes, because a
system-local framework such as systemd is too limited to express the
dependencies. System boot time is significantly less important than service
response time, so "socket activation" for daemons is not useful in this
context either. We have had this for -literally- decades in the form of
inetd, and it has not been widely used, precisely for that reason.

The "desktop" and "server" use cases are so vastly different that it
doesn't make sense to try to squeeze both into a single design, because it
will not be good at either. There are other use cases that have
requirements that are not adequately serviced by either, for example
embedded systems or containers.

It is way more useful to have multiple alternatives that fit their
respective use cases well than one thing that attempts to do everything.

> So then the question boils down to what kind of feature
> development sysvinit *in Debian* is willing to do to do that. If the
> answer is "we really want the shell scripts as they have been since
> the beginning of time - and that is the scope of sysvinit" (which
> would not be true either, I know), then we cannot have that
> discussion either.

It is pretty close to the truth. The SystemV init design boils down to

 - there are two phases of system boot: kernel services (rcS.d) and user
   services (rc[1-5].d). User services can depend on kernel services.
 - configuration files are in an imperative language

The systemd design on the other hand:

 - there is a dependency tree of services that may depend on each other
 - configuration files are descriptive, with an exception for generators,
   which are imperative, but generate descriptive configuration fragments

The scope of sysvinit is to provide a minimal framework and then get out of
the way. Daemons can expect a working file system and to be able to create
listener sockets on INADDR_ANY or IN6ADDR_ANY. Anything beyond that is the
responsibility of the daemon.

The NTP daemon for some reason binds one socket per configured IP address,
so it needs to watch for network configuration events. Offloading that
responsibility into a common component would probably be possible, but
would not save any complexity because the main task of coordinating these
changes with the efforts to adjust the system clock would still be there.
As a result, it doesn't make any sense to make ntpd dependent on systemd
for its socket handling, and the only thing systemd is useful for is the
same thing that sysvinit also does: start the daemon some time after early
boot is complete.

The sanest thing we could do in Debian is to teach start-stop-daemon to
parse systemd .service files and pull its command line arguments from
there, so we could use service definitions as init scripts with a #! line.

For that to happen, we'd have to define .service files as an API though,
which would feature-freeze them, and I'm not sure the systemd people would
be happy about that.

For systemd-only services, it makes the most sense to spawn a per-user
systemd instance when they log into a graphical desktop environment.

System-wide systemd-only services past the early boot stage are just bad
design, do not currently exist and we shouldn't encourage their creation.

   Simon