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.
