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):

  • managing user logins
  • the DNS resolver
  • network configuration
  • network device name management
  • system logging
  • privilege escalation with sudo and su
  • mounting storage devices

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:

  • system logs, instead of being nice simple text files like /var/log/messages and /var/log/syslog, are in a binary format that only journalctl can help you decipher. Good luck if that binary file gets corrupted.
    • note that Debian, at least, is sensible enough to set systemd's logging back to plain text files by default - which can be done, but isn't standard, and not all distributions do - a binary system log format is just one indication of what the systemd developers think is sensible, and I do not
  • network devices, instead of the standard eth0, ppp0 etc, can end up with names like wwp0s20u2i1. Hmm, yes, I can see how that's an improvement…
  • starting a 'screen' (or 'tmux') session, running a process in it, detaching from 'screen' and then logging out (which is surely the main purpose for using 'screen' in the first place) now results in your process being terminated when you log out. systemd thinks that any process your login session started should end when you log out (thereby defeating the object of useful things like 'screen' from the start)

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.

Powered by DokuWiki