16 Jun
2024
16 Jun
'24
11:48 a.m.
Grant Taylor via TUHS <tuhs(a)tuhs.org> writes:
I'm anti-systemd *cough*Master Control
Program*cough* and it's
associated suite of utilities for many reasons. But I've come
to
accept that systemd is not just an init system. It's role of a
service life cycle manager is a superset of what an init system
does.
It's a relatively new world (at least comparatively).
Indeed: it doesn't just do init, but also _service supervision_
(making sure that a service that _should_ be up, _is_ up) and
_service management_ (enabling, disabling, starting, stopping,
dependencies, etc.). Hence why phrases like "the init wars" are
such a misnomer.
As described in the potted history outlined in the "known problems
with System 5 rc" article i linked to upthread, Sys V rc's issues
with service supervision and service management have been known
for decades:
In 1999, Luke Mewburn worked on replacing the /etc/rc
system in
NetBSD. netbsd.tech.userlevel mailing list discussions from the
time show several criticisms of the System 5 rc and System 5
init systems, and encouragement not to repeat their mistakes in
the BSD world. The resultant rc.d system was roughly
contemporary with Daniel Robbins producing OpenRC, another
System 5 rc replacement that replaced the (Bourne/Bourne Again)
shell with a different script interpreter, nowadays named
/sbin/openrc, that provided a whole lot of standard service
management functionality as pre-supplied functions. The NetBSD
rc.d system likewise reduced rc.d scripts to a few variable
assignments and function calls (in about two thirds of cases).
The initial release of OpenRC - still Gentoo's 'native' system for
service management - was in April 2007; the initial release of
systemd was in March 2010. But although both OpenRC and systemd
address various pain points of Sys V rc on Linux, systemd has
_also_ had the backing of an 800-pound gorilla in the Linux world
- Red Hat - which has _implicitly_ forced its adoption over
alternatives by distros that don't have the same level of
resources behind them.
Here's an excerpt from something i wrote on the Gentoo forum back
in April:
There's been so much anger and vitriol expressed
about
systemd. Has that significantly slowed the systemd juggernaut?
Not really. Not least because, as in the case of D-Bus, and as
in the case of Wayland, it addresses very real issues for
significant numbers of people.
For example: unlike on, say, OpenBSD, which has developed a
pretty clean shell-script-based service management system, with
a 'standard library' in the form of rc.subr(8), the situation on
Linux was a mess. Many of the (usually volunteers) who maintain
packages for Linux don't want to have to learn the complexities
of shell scripting and the subtle issues that can arise, or
develop and maintain workarounds for race conditions, and so
on. systemd comes along and says: "Hey, with systemd, you'll be
able to write service definitions declaratively; you won't need
to wrangle shell scripts." That's a pretty attractive
proposition to a number of package maintainers, and in the
absence of systemd alternatives explicitly providing such an
interface - not just saying "oh that could be done on our
alternative" - those maintainers are going to be inclined
towards systemd, regardless of what design and implementation
issues are involved in systemd's approach.
So in wanting to try to ensure that myself and others have
choices and alternatives available, i feel that ranting against
the incoming tide, like a tech King Cnut, is typically far less
effective than actually putting in the work to develop and
support those choices and alternatives.
Alexis.