On 1/23/21 8:27 AM, Mark Rousell wrote:
>
> As I understand it the initial impetus for SystemD (as with all the 
> other competing init systems) was the perception that SysVInit was/is 
> obsolete or not suitable for modern life. One of SystemD's claimed 
> advantages over SysV was faster booting. However, in my experience 
> similarly specced SysV machines seem to boot faster!

The systemd init system didn't directly replace real SysVInit; in RHEL 6 
Upstart was used as the init.  I've used systems from before SysVInit, 
where the init system was rc.local (and not much more than just rc.local).

Straight SysV init does not meet the needs of many server setups, 
especially server setups that need to dynamically change the daemon mix 
that is currently running.  Virtualization hosts, software-defined 
networking setups, and what is typically called 'cloud' services are use 
cases for things systemd does well.  The antiquated concept of runlevels 
works fine for relatively static workloads; not so much for more dynamic 
workloads on the server side.

> It's difficult to say anything about SystemD without it becoming 
> political/religious but my impression is that the bloat and mission 
> creep that SystemD seems in many people's views to suffer from (i.e. 
> it is no longer just an init system) is perhaps less about "software 
> engineering and design justifications" and perhaps more about 
> mindshare grab and ecosystem control. I claim nothing; I merely report 
> common views. ;-)
>

Difficult?  That is the understatement of the decade.  I prefer to 
honestly evaluate new technologies with a bit more pragmatism; do I like 
having to learn a different way of doing things?  Not really; but after 
Debian adopted systemd I took more notice.

In my opinion, the single greatest advantage of systemd is that the 
files that define how the system starts up are no longer executable 
shell scripts that typically run as root.  I maintained some of those 
shell scripts for a major open source database's RPM package several 
years ago, and the fact that the scripts I wrote that very few admins 
ever looked at and checked up on were running as root on thousands upon 
thousands of machines.... well, there are better security models in the 
world.  Oh, the database was PostgreSQL, by the way.  The systemd init 
itself is larger than the Upstart init (for EL 6.x) or SysV Init (EL 5 
and previous), but the potential vulnerability footprint is much 
smaller; instead of having to audit thousands of initscripts that ALL 
get to run as root you audit one package or set of packages.

But even then virtually every systemd installation will happily run a 
SysVInit-style initscript (and will log to /var/messages in plain text), 
just like Upstart before did in EL 6 (well enough that people forget 
that EL 6 didn't run a straight SysV Init anymore).

SysV Init was a substantial upgrade from what came before (I remember 
those days, running Xenix V7 and System III), but in today's 
containerized, virtualized, dynamic server world it simply isn't 
sufficient for a large enough percentage of real-world server workloads.