What's wrong with systemd?

Linux used to be based on SysVinit for starting and managing processes; some distributions have experimented with upstart; now most distributions are based on systemd.

What's the problem with that?

Well, if it were only a change to the init system, and the way processes are started & stopped, maybe it would be okay.

But it's not - systemd has gradually infiltrated an incredible amount of how a Linux system operates, so that it's no longer just a GNU/Linux system, it's a GNU/systemd/Linux system.

Also, even the way systemd manages process startup & shutdown has aspects which I (and many others) don't like. The principal one of these is that system startup is no longer deterministic (which means you can't be sure your machine is going to (try to) start up in the same way each time).

This "feature" (?) came directly from one of the original design goals of systemd - to enable processes to get started in parallel with each other, in order to reduce the boot time. However, a big side-effect of this is that processes no longer reliably start up in the same sequence every time you boot your computer. Sometimes they will, but sometimes things will be different. Personally, I'd prefer to wait a few more seconds for the machine to become ready, but know that if it has a problem, it's nothing to do with which way round some things started up on this occasion, compared to previous occasions.

Starting things in parallel makes it more difficult (for me, at least) to follow the system boot messages - if I am trying to debug some problem, I prefer to have a clean display of what's going on when, without several processes all starting up at once and getting in each other's way as I'm trying to read the startup output.

However, returning to my biggest grumble about systemd infiltrating its way into a Linux system, it gets involved in (amongst other things):

This is by no means a comprehensive list, but it's an example of how far what was originally a replacement for init has come in taking over the rest of the system.

Some of the side-effects are:

systemd is simply not "the Unix way" of doing things - a simple tool to do a specific job, which you (as a user) can then put together with other simple tools if you need to do a complicated job. If you need to write a program in Perl, then write it in Perl, but if the task is simpler than that, then use grep, sed, cut, tr and maybe even awk, piped together to achieve what you want.

We have cat and tac; we have rev; we have tr, cut, sort and uniq - all wonderful examples of tools which do a simple job, and do it well.

Similarly we have syslog, /etc/network/interfaces, named, mount, sudo and init - and I'm perfectly happy with the jobs they do, instead of trying to replace them all (and more) with one over-arching concept which aims to take over my system in the same way as The One Ring aims to take over all of Middle-Earth.

Finally, I'm distinctly bothered when I read some of Lennart Poettering's (the lead developer of systemd) ideas about computing, such as deciding to turn off the error correction facilities of BTRFS, just because his "journald does checksumming"…

I don't want someone like that being responsible for large parts of the code running on my computer.


Go up
Return to main index.