Systemd has these stupid config files. And by stupid, I mean that literally. They replaced init files (with arguably too much logic) with these simplistic config files that have no logic available.
What ends up happening is you replace init files with nothing, and you have to push out any logic to an intermediate script or binary which just adds indirection.
I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain Linux servers. systemd is a great addition to the Linux server ecosystem. It's infinitely easier to write a systemd init script that is functionally correct, than it is to write the equivalent init script in shell.
> It wasn't broken, so it did not need fixing / rewriting.
Writing a robust init script in shell is a HUGE pain. Every distro seemed to have their own tools and methods for writing init scripts (e.g. Red Hat had /etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them sucked. systemd makes it easy (and for the most part, portable across systemd distros).
I have never encountered the need for this and I honestly doubt you have either. Systemd fails mysteriously far less often than poorly written init files I have seen and it is honestly not that hard to debug almost every failure I've ever encountered. And I have worked on some very large scale systems with systemd. A systemd file I helped write has run many millions of times over without issue. I honestly find this comment impossible to believe
But system init is a hard, complex problem. You can’t create a simple solution for that, since there is an inherent complexity. I prefer systemd over having a bunch of bash scripts trying to do service restart, logging, dependency management and failing at it. You would still get the same complexity but at a different (worse) level.
It's much less than that, but it's sort of an uninteresting demo I think - you could pretty easily write an init process that just spawns systemd in a container, for instance, and run the whole system in a container. Or write an init process that spawns systemd as pid 2, runs prctl(PR_SET_CHILD_SUBREAPER) to make pid 2 responsible for reaping instead of pid 1, and then sits around carefully doing nothing. If systemd crashes, whatever, hopefully sshd etc. are still up.
Of course, if you do that then the question is why even bother with an init process. Patch the kernel to not treat pid 1 specially. If a process gets orphaned, don't reparent it to init, just reparent it to nonexistent pid 0. Have the kernel deal with the thing that the 10 lines of C would be doing (waiting on processes to terminate).
I think there are meaningful complaints about systemd but the fact that it's a complicated pid 1 is not one of those. If it were actually a problem someone would have written and productionalized one of the above two approaches.
systemd doesn't appear to solve a problem, it seems to just add a layer of indirection and complication, as well as a single point of failure for ALL system startup services, rather than letting each service just handle it's own deal.
`init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
I don't think the idea of systemd is wrong. Long time ago out of curiosity I decide to learn how the boot process works and examined the code. It turned out, the init system was written as a bunch of shell scripts.
Its creators probably tried their best to write it, gave functions good names, left comments sometimes, but still it was bad. Running several subprocesses to split a string into parts. Parsing text output of subprocesses. Creating unnecessary temporary files.
This style of programming leads to extremely fragile systems. If the command slightly changes its output, scripts will break. If the command output depends on locale, scripts will break.
Futhermore, there is no sane options for error handling in shell scripts. There is only a relatively sane option - crash on any error and an insane option - ignore any erros and continue. For example, we failed to backup a file, but ignore this error and delete the original. No way one can write something reliable using such tools.
So if you want to write an init system, I think there are better languages that a shell script. It is difficult to build a graph of services and find an optimal sequence to start them using shell scripts. Or implement lazy startup of non-critical services.
Init system is not only a program to boot the system, but it should provide some runtime services, like management of background processes, logins and other things. Again, a properly written daemon with an API is better than a bunch of shell scripts.
Regarding languages, I am not sure if C is good for this purpose, it's pretty awful too. To illustrate this, consider a C function declaration:
int set_working_directory(char *new_directory, char **error);
You cannot figure out how to call this function properly without documentation or examining the code.
Instead of C I would choose something like Swift, D, Go (but it has pointers), maybe Rust (but writing in Rust for me is mostly struggling against borrow checker). I would choose something that's easy to read, test and verify and has a package manager.
So if you don't like systemd, consider writing your init system using one of the languages above. But please don't use shell scripts anymore.
It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page.
A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:
So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.
Note the irony of the situation. Writing an init.d script is actually really hard. A post attacking Systemd is actually a pretty good argument for using it.
I wish we could have a systemd that JUST does the job of init, and leaves the system logging, DNS resolving, etc. to the prexisting software that does a better job of it.
Systemd is a swiss-army-kitchen-sink-knife monolith of brittle complexity.
A proper init system similar to runit or s6 would be written in something safer (minimum unsafe) like Rust, be modular, simpler, follow UNIX philosophy, and not try to do everything in one process. Microkernel-style.
I've had way more headache with badly written and plain faulty init scripts than with systemd, including systemd-networkd, systemd-timesyncd, systemd-resolved and systemd-nspawn, which I used to replace a lot of LXC, LXD and openvz setups.
I remeber seeing someone post one of the simplest init process one could write. It was only about 100 lines of C.
reply