systemd vs SysV
(No troll intended) Here's the VERY interesting answer made by Bryan J Smith. Keeping it here so that I can read it again later and get a clear picture of all this.
Fri May 29 07:34:54 2015 - permalink -
Short Answer ...
Since Arch, SuSE and Red Hat all adopted it early on, as well as CoreOS being completely dependent on it, along with the sister *d services and *ctl programs, it's a good idea for any practicing Linux professional to learn them, whether they agree with them or not.
Despite common demonizations, systemd is very modular (not monolithic), with a "core" component, lots of sister *d services and *ctl programs, and many optional or even disabled by default supplementary services (that do not need to be required, just optional). The needs of the cloud generation of services have basically caused the creation of something like the *d solutions.
But the collection of the various *d solutions are not systemd, even if people blindly associate them as systemd, and claim it is monolithic, doesn't do only one thing and do it well, etc... In reality, SysV init does not do service management well at all, and that's why everyone has been trying to create a replacement for years, including Upstart.
Long Answer ...
The *d services and *ctl programs address a lot of issues that static scripts cannot. This includes more than just the dynamic "core" systemd components, but also dynamic services like firewalld, nm* and other solutions, especially with newer subsystems like libvirt for virtualization and, even more so, containers.
E.g., if I made a static iptables change (whether I was using lokkit or not), I often found myself having to reload libvirt, if I had any constainers running. This also goes to why solutions like CoreOS (a lightweight, container-host driven Linux platform) use the *d solutions by default.
This is in addition to the long-standing issues both SuSE AG and Red Hat customers were having with real-time resource dependency monitoring -- not just real-time service dependency monitoring.
E.g., a file system becomes unavailable, and it takes a bit of troubleshooting to track down that as the root cause due of why a service is failing, or partially failing. The built-in, dynamic dependency checking of systemd does that inherently.
A lot of customers were already using monit or even Luci/Ricci (clustering services), on a single system, to do similar, because Upstart did not either. And that's the thing, it wasn't that people thought the *d's were the best solution, but nothing else did such. Even for just services, Upstart required manually defined service dependencies, whereas the systemd design can detect port, service and other dependencies dynamically.
Which is also where most people get frustrated with systemd. E.g., They don't realize all that systemd will do to solve dependencies, and why you have to do more than just stop a service, but disable it entirely.
And that's before we visit recovery.
Despite a lot of demonizations out there, systemd actually makes recovery much, much better. Despite many attempts, no one ever came up with a solution like journald to capture those key, early boot messages that would often be lost if the system never reached the point where a syslog solution was used. systemd also introduces a minimal recovery mode that is far more deterministic.
E.g., systemd's recovery image loads all of the required modules, whereas init=/bin/bash can utterly do nothing of the sort -- with the latter often making it too easy for people to cause storage corruption in many cases of required support.