Arguments against systemd

Conceptional problems

Systemd Prevents the Skipping of fsck while Booting - still unresolved
Systemd Disables the Linux Magic SysRq Key - closed as "NOTABUG"
Please do not default to using Google nameservers - Debian package maintainer refuses to acknowledge the privacy leak and closed the bug.
timeX.google.com provide non standard time - Horrible default behaviour but Lennart tries to shift the blame on distros because "systemd is not a product".
Do not parse "debug" command line parameter - Response on LKML Response: That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.
journal ip anonymization - It's very difficult to use systemd/journal on a privacy aware system or infrastructure.
systemd kill background processes after user logs out - Poettering's answer: In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.
systemd-resolved is broken - doing DNS resolve wrong, with the usual attitude towards feedback

Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: A side-by-side look at run scripts and service units

Poor design

Improper argument parsing
systemd has a filename that starts with a hyphen! - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, "-.slice", they refer to as the "root slice" which causes confusion as the term "slice" has been used for decades as an alternative way of referring to a disk partition yet their usage is completely unrelated.
systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' See also No POST after rm -rf / - Lennart's argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the principle of least privilege. Lennart goes on to state that systemd needs to write EFI variables. This demonstrates yet another example of scope creep and thus poor design.
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854
https://bugzilla.redhat.com/show_bug.cgi?id=1170765
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 "Now you can no longer expect a long running background processes to continue after logging out. For example, you can no longer start a screen or tmux session, log out, and expect to come back to it."
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ systemd's predictable NIC names are actually unpredictable...

Scope creep

systemd assimilates udev
systemd takes over logging (and as if that wasn't bad enough, it uses a binary format)
systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls
Gummiboot UEFI boot loader to be added to systemd
DNS cache --- systemd-resolved
web server
systemd developer asks tmux to add systemd specific code
An init system that requires even on a server a library for rendering QR codes: Post in Heise Forum and reference in Fedora
systemd assimilates mount

Scope creep leads to vulnerabilities

systemd-resolved DNS cache poisoning
To run systemd properly in container a FUSE LXCFS had to be created, and surely its own share of vulnerabilities:
- LXCFS before 0.12 does not properly enforce directory escapes CVSS 4.6
- The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions CVSS 7.2
systemd vulnerability allows attackers to hack Linux machines via malicious DNS response

Absurd bugs and responses

Unchecked null pointer dereferencing in PID 1 not considered a serious issue - "To make this work we'd need a patch, as nobody of us tests this.", "I will not work on this" - systemd requires cgroups and segfaults if there is no cgroups support.
Screen locking issues (including a security issue) with gnome-shell - remained unfixed for over a year]
PID 1 segfaulting on upgrade; journalctl usability issue - bug report still marked as "NEW"
"Tried to boot my laptop from a cafe..."
systemd segfaults after updating from 208-23.3 to 208-28.1
Mount efivarfs read-only - Doing rm -rf / bricks your computer
Unable to shutdown
journald eats up CPU
Corrupted binary logs
how to crash systemd in one sweet (works as any user, not just root) and response and rebuttal
systemd v228 local root exploit
tmpfiles: R! /dir/.* destroys root See also systemd again (or how to obliterate your system), Poettering's response: "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?" (Hint: no.)
systemd can't handle the process previlege that belongs to user name startswith number, such as 0day Poettering: "not a bug, a feature"
systemd Using 4GB RAM After 18 Days of Uptime

Breaking promises and immaturity

"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time"

"...this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call."

Linux (kernel) coup attempt: "kdbus support is no longer compile-time optional ... We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled." comment on this on LKML

"The kdbuswreck"

"kdbus now out-of-tree"

"kdbus dropped in favor of BUS1"

unmet stability promises:

To quote from the systemd stability promise:

"Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future."

One of their promises is for the export format:

"Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores. "

This is not true for version 44 of systemd for example.

Ignorance of fundamental operating system concepts

Lead systemd developer doesn't understand RAID or checksum
Lead systemd developer doesn't understand su, expects it to do something else and then labels it a "broken concept" - su isn't supposed to inherit cgroups or audit, those concepts are relatively new and arrived well after the creation of su. TTYs were originally physical devices so of course su is supposed "inherit" the same device otherwise it would be truly broken. Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical. su really is just a simple mechanism that calls setuid(2) in order to switch to another user. If he needs to write a new utility to handle scenarios that su was never designed to handle, no problem, but to label it as a "broken concept" demonstrates a lack of understanding of what su actually is.

Arguments against systemd

Contents

Conceptional problems

Poor design

Scope creep

Scope creep leads to vulnerabilities

Absurd bugs and responses

Breaking promises and immaturity

Ignorance of fundamental operating system concepts

further reading: additional links

Views

Personal tools

Navigation

Search

Tools