What is systemd and why is it hated?


What is systemd and why is it hated?

In: 7

The purpose of systemd is to enforce consistency. As a result, it’s not “the best solution” for some cases, particularly on the simple end of the scale. Developers like to gripe about having to do thing some specific way, it impacts their “artistic freedom”.

It’s “new” and different. Some people hate that.

It’s a structured way that largely replaces init startup scripts and some other system services.

When the computer boots up and have started the kernel with all the device drivers and such it needs to start all the services and processes to complete the boot process. In UNIX and Linux this have traditionally been handled by sysVinit. This is a fairly simple system that basically just runs a number of shell scripts from a folder. At the time it was written this was more then adaquite. But since then we have seen a lot of features of similar systems in Solaris, Windows, OSX, etc. Things like restarting services when they failed, starting services in parallel, handling dependencies better, starting services on demand, etc. However people have grown fond of sysVinit and there are tons of scripts and knowledge working with it. Every project that implements a daemon for Linux comes with a script for sysVinit. But there have been attempts at replacing it for some time now. And it appears that systemd have won forth to become the new standard service management platform for Linux. But this basically means that all the Linux system administrators needs to get back on the school bench and learn all they know again. And all the projects that comes with scripts for sysVinit now needs those rewritten to take advantage of the new features in systemd.

On top of that the developers behind systemd did not feel comfortable stopping at replacing one piece of ancient software. There are lots of software written in a hurry by a student intern at MIT in the early days of UNIX which is still around. Best example of this is vixiechron which was written as a quick hack to run a script every two hours until Vixie could return from his Summer vacation but is still with only minor changes the main way to schedule regular executions of software. And because this is a natural part of service management the developers behind systemd replaced that while they were at it. And then replaced the log system, and the time keeping system, and so on.

Now, all of this additional projects are optional and systemd does work with the old projects and the new projects work with software written for the old projects. However it have become quite different to work on a modern Linux distribution that makes systemd and many of the sister projects default. And they are not so simple as the old ones meaning that you have to rely on the documentation more then just looking at the code itself. It is certainly a very different way to work, and if you understand it then it is much better as there are lots of features built inn.

systemd handles the tasks of getting various background processes on a Linux system up and running; it replaced an earlier method, *init*, which was arguably simpler and easier to work with.

From Wikipedia:

The design of systemd has ignited controversy within the free-software community. Critics regard systemd as overly complex and suffering from continued feature creep, arguing that its architecture violates the Unix philosophy. There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software comes to depend on its components.

Others have touched on the major points, but the two that have burned me:

Needlessly obtuse binary logging format, and difficult-to-read output from the tools to access the logging facility. Very often you’ll have a service start failure, run ‘journalctl -xe’ or whatever it recommends, and get a half screen of crap that doesn’t even include the program’s output.

Bad defaults for many use cases (e.g. terminating your tmux/screen session after logging out of SSH, thanks for letting that one through, Debian)

The person/people (who will not be named) who wrote it will (semi-justifiably) pass the buck to the project managers.

It’s really easy to write it off as a “let’s make Linux more like Windows” thing, but it does have a decent set of features now. The justifications for hatred for it have waned in my mind, though I admit I don’t have to interact with it from day to day. It does, however, remain somewhat annoying.

edit: also, my usual (if available) solution for log-eating is to just have the things I care about send to my main computer’s syslog server and forget about it. I’ll do my own log centralization, thanks.

From what i’ve experienced, systemd hatred can be summarized by 3 major things:

1 – Systemd makes itself into a dependency of other applications or makes other applications need to alter their behaviours to account for it. For example if you want to run a Windows virtual machine on your PC then you are expected to register it with systemd as a virtual machine. … Why? Well, as others have pointed out failure to do so may result in systemd killing your virtual machine under certain situations. This means the software making virtual machines needs to be systemd-aware now and register the Windows VM, partially to protect it from such actions. If it was not, your VM might be terminated and the response from systemd authors would be that your VM software needs to talk to systemd.

2 – Hinted at in my first item, the lead developer(s) have not been very well received by the greater community. There was a rather famous situation a number of years back where someone’s logs from systemd’s log collector were damaged and unreadable. The response was to just delete them and move on. The advice to just delete your logs is not a good one for a system administrator. Logs tell you what’s going on and help your find problems. The notion that you should just throw them away is a sour one.

3 – There have been a large number of concerns with the code quality. Many security issues have been found in systemd over the years. Systemd runs as process #1 on Linux meaning it has full administrative privileges and if it crashes then the whole system crashes with it, effectively a bluescreen of death. Consequently the traditional philosophy is that the program in this position should be as simple and dumb as possible. systemd turns that on its head making it into a service manager, login session tracker, and all sorts of other things allowing non-administrative users to send it messages. Personally I can say that on servers with a lot of logged messages going on it’s the systemd log service that’s the bottleneck… even if it just forwards the messages all to another application. But I can’t get rid of it so easily and I’m stuck with the bottleneck.

Now systemd does bring a lot of good things with it. Linux has lacked a well received general purpose service manager in its life which systemd provides. From my personal standpoint though, that is the *only* redeeming quality I have found with it and that doesn’t nearly offset the bad stuff that comes with it instead. Given the choice I would not use it.