> It's dramatically simpler and more intuitive than what it replaced
I hope you're being deeply ironic.
It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.
> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
You're not disagreeing with anything I said. You're making a completely different point.
systemd might be more convenient from the point of view of an end user. And unit files might seem superficially simpler than a script.
But systemd is not simpler. It provides significantly more complexity, while also providing a lot of features.
systemd is also not more reliable. The previous system, even with LSB dependencies, was usually run in a linear mode with scripts run in a strict sequence. System boot and service startup was deterministic.
If you read the part of the linked article about the sheer quantity and complexity of the internal state managed by systemd, and how it is not deterministic, or even fully understandable even by its authors due to the combinatorial complexity of all the options and how the same settings work differently in different contexts, I'm afraid that I can't do anything further to convince you about the significant design problems it has which directly impact its reliability. Never had it hang irrecoverably at boot, for no discernible reason?
There is a reason people such as myself are appalled by its design. It doesn't even have a comprehensive specification for such a critical piece of functionality. It's defined solely by a single implementation.
The systemd state is a massive hairball. It's effectively a black box, and understanding why the system exhibits certain behaviours is difficult.
The sysvinit state consists of a current runlevel and the state associated with inittab tasks, which is pretty trivial. It doesn't attempt to maintain a mirror image of the state of the whole system, which is largely a constructed fiction.
Systemd is not only more convenient, it's also more simple.
Proof? sysvinit's surface is anything you can call. It's internal state is everything on the system.
Systemd's surface is the (well documented) commands in the systemd unit files. Each unit is pretty much independent, the dependencies are specified and well defined. Their internal state can be examined and explored.
It's interesting how many people have such wildly different experiences with systemd.
For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it).
The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.
But I've been using systemd for a long time (since Fedora 21). Maybe we're all coloured by not only when we first encountered it but by our distro and how simple they make things? FWIW I'm using Debian and Arch these days and still struggle to "enjoy" systemd, but it definitely functions better on my arch machine.
> For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it).
I don't understand how this is an horrible thing. Thanks to it you can do stuff as
and have an interactive representation of your boot flow graph, where you can click on any node to highlight any other dependent node. This is super nice ! systemd-analyze critical-chain was also very good to try to find out which service was keeping my NAS stuck for 5 minutes on boot.
The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.
To give you my experience I was never able to do anything with older systems without reading tutorials on the internet while with systemd I'm able to solve my problems with man systemd-whatever most of the time, e.g. just look at `man systemd.service` or `man systemd.network` with actual configuration examples for common use cases
Read: A confusing mess of different daemons, scripts, and configuration files, which neither worked together elegantly, were simple to configure, nor were easy to debug. Before systemd I would avoid writing custom daemon configurations at all costs because when I did I would need to learn how this version of this distro did it, fiddle with the byzantine mess of scripts, and inevitibly debug multiple subtle issues, now it's basically trivial to get a new daemon running, and I extremely rarely need to debug issues (And I have had to track down systemd bugs due to obscure use cases like one systemd unit modifying other systemd unit configs at the same time another systemd unit with multiple execstart lines is running).
I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user.
With systemd? 5 lines or so of boilerplate, independent of distro.
Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple. It's systemd being easy.
Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.
I've run across a couple of cases where the "depends on" part seems to intermittently fail. That is, the implementation seems to end up with a race. That presumably means that the dependencies were specified incorrectly, but getting it right seems to be quite difficult. Or, conceivably, it's a bug in systemd, but debugging that is a lot harder than debugging a couple of tiny shell scripts.
I'm not necessarily a "remainer" on the subject of systemd, but I think it's not correct to sell it as a huge win on simplicity. Maybe it is simple when everything goes right. When it doesn't, though, systemd is fairly nasty to deal with.
As a user, systemd wins for me hands down, because it is simple to use. That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier.
Now if you are measuring the complexity of the system's (full) implementation, you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based system.
And then you need to account for the 100s of inconsistently written shell-scripts, all the code distributed in the mess of third party dependencies (sh, bash, Perl, Awk, Python, su, supervisord, cron, etc) to ensure that the functionality of the systems you are comparing is really somewhat equal, not to mention the added complexity of the glue between all those components, and how it may fail.
And when you do that comparison, I do believe you will end up concluding that 1. full systems are somewhat complex, for both systems, and 2. that systemd-based systems are not fundamentally more complex, and 3. systemd-based systems have the benefit of a single, centralized implementation for all these core functions, so that developers don't have to reimplement them inconsistently, and possibly buggy.
With systemd, for better or worse, either your entire init-chain is broken or it isn't, so when it works, you know it works. With SysV-init you have no such guarantees.
Depending how you look?
Here is a great example: disable the service before installing -- i.e. make sure that even if someone installs the service, it won't get activated.
On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.
