systemd:
An Indictment

When Lennart Poettering introduced systemd in 2010, the pitch was seductive. A unified init system, faster boot times, proper dependency management, socket activation. The Linux init landscape in 2010 was genuinely messy. SysVinit was old. The shell scripts were fragile. Upstart, Canonical's attempt at a solution, was already showing its limits.

Poettering had a real problem. His solution was, in important respects, the wrong answer to it. And the way that wrong answer conquered the Linux world tells us something important, not just about software, but about power.

The first thing to understand is that calling systemd an "init system" is like calling the Roman Empire a "city administration." Technically true of its origins. Completely misleading about its current nature.

systemd today manages: process supervision (PID 1), logging (journald), network configuration (networkd), DNS resolution (resolved), time synchronization (timesyncd), login sessions (logind), device management (udevd, absorbed from kernel team), container management (machinectl), hostname management (hostnamed), locale configuration (localed), bootloader management (systemd-boot), home directory encryption (homed), credential management (systemd-creds), cryptographic enrollment (cryptenroll), partition management (repart), firewall integration (nftables hooks), and core dump handling (coredump).

This is not an init system. This is an operating system layer.

A fair objection arises immediately, and it deserves a direct answer: not all of these components run inside PID 1. systemd's own architecture documentation confirms that many subsystems — systemd-resolved, systemd-networkd, journald — are separate daemon processes. The service manager running as PID 1 communicates with them rather than containing them. Poettering made exactly this argument in his 2013 "Biggest Myths" rebuttal. It is not untrue. But it is incomplete as a defence, for three reasons that matter architecturally.

The shared codebase problem

All these separate daemons are compiled from the same repository, share the same internal libraries (src/basic/, src/shared/, libsystemd-shared), and are maintained by the same team under the same release cycle. A vulnerability in a shared library component potentially affects multiple daemons simultaneously. When CVE-2021-33910 was discovered, it was in systemd's unit name parser — code shared across the system. A bug in shared infrastructure is not contained by process separation.

PID 1 has a network-reachable attack surface

PID 1 still parses D-Bus messages at runtime. The bus_process_object() function in libsystemd/sd-bus/bus-objects.c — the one at the centre of CVE-2019-6454 — allocates stack buffers for incoming D-Bus messages and delivers them to PID 1 directly. The process separation defence does not apply to the interface between PID 1 and the rest of the systemd ecosystem. PID 1 has a network-reachable attack surface that simply did not exist before systemd.

The failure blast radius

In a modular system, a journald crash loses you logs. In systemd's integrated ecosystem, a journald crash during boot, or a resolved hang, or a networkd race condition can cascade through unit dependencies in ways that prevent other services from starting. The unit dependency graph that systemd manages is impressive engineering. It is also, by design, a single point of failure coordination.

Critics of the anti-systemd position often dismiss it as nostalgia. Old men, they say, clinging to shell scripts and 1970s aesthetics. This is a rhetorical move designed to avoid engaging with the actual argument.

The Unix philosophy is not an aesthetic preference. It is an engineering discipline with demonstrable consequences. The principle of small, composable tools doing one thing well is not a relic. It is the reason Unix-derived systems survived and dominated for fifty years while monolithic competitors died.

CVE counts do not measure code quality. They measure reported, catalogued, and confirmed vulnerabilities. The number of CVEs is not a verdict on the competence of the developers. It is a direct function of scope. When you compare systemd's CVE count to that of runit or OpenRC, you are not comparing the quality of two codebases. You are comparing the attack surfaces of a Swiss Army knife and a scalpel.

The comparative data

runit has one CVE attributed to it in the public databases: CVE-2006-1319, a group permission handling issue in chpst for a specific build configuration on Debian, nearly two decades ago. One CVE. One.

s6 has no CVEs attributed to it as a standalone project.

OpenRC's complete CVE history is small — single digits across its entire lifespan — and none affect the init system's core supervision function.

systemd has accumulated dozens of CVE entries including: vulnerabilities in systemd-resolved (DNS manipulation, DNSSEC bypass), systemd-journald (out-of-bounds read, memory disclosure), sd-bus in PID 1 (stack exhaustion causing kernel panic, CVE-2019-6454), systemd-tmpfiles (uncontrolled recursion, denial of service at boot), systemd-networkd (DHCP spoofing via crafted FORCERENEW packet), and logind (privilege escalation via polkit race conditions).

CVE-2021-33910 reconsidered

systemd's unit name parser — code that lives in the shared infrastructure linked by multiple systemd components — can be triggered by a malicious string in /proc/self/mountinfo to exhaust the stack of PID 1 and cause a kernel panic. An administrator cannot configure around this. The only mitigation is the fix. A system where a crafted entry in a virtual filesystem can kill PID 1 has a specific kind of fragility that does not exist in runit, OpenRC, or s6 — because none of them parse mount tables in a process that manages every other process on the machine.

On the "local access" defence

Many of systemd's more serious CVEs do require local access. The response is not to dismiss this but to contextualise it. Local privilege escalation vulnerabilities are serious on multi-user systems, shared servers, and container hosts where untrusted processes run alongside privileged ones. These are precisely the environments where Linux dominates. Furthermore, the architectural argument does not depend on any specific CVE being weaponisable. A larger attack surface represents a larger risk, independent of whether a given vulnerability has been exploited in the wild. This is the foundational principle behind attack surface reduction, endorsed by every major security framework including NIST, CIS, and the NSA's own hardening guides.

The text export capability of journald is real. journalctl -o export, journalctl --since, journalctl -u servicename — these work. The objection on this point is valid, and framing journald as simply opaque is a half-truth.

The architectural critique, however, survives this concession. The question is not whether journald can emit text. The question is what happens when the journal is the primary log store and you need to access it without a working systemd installation.

A corrupted plain text log file is recoverable. grep, awk, tail, and standard Unix tools operate on it regardless of what state the rest of the system is in. A corrupted journal database requires journalctl, which requires a working systemd userspace, which requires the system to be in a state where you are trying to diagnose why it is not working. The dependency is circular in precisely the failure cases where you need it most.

The forwarding-to-syslog capability also requires configuration. The default in many distributions is to not forward. Defaults matter enormously in practice. A system that logs to a binary format by default, without forwarding to plain text by default, has made a specific choice about who its administrator is and what their expectations are.

On a systemd-free system using runit or OpenRC, your logs are in /var/log, in plain text, right now. No daemon required to read them. No binary format to corrupt. No journalctl --rotate to memorize. Just files.

The original critique of D-Bus was overstated, and the objection is largely correct. D-Bus, whatever its desktop origins, has been effectively adapted for system-level use. It is used outside GNOME, outside the desktop environment context, and in practice functions adequately as an IPC mechanism for system administration.

The more defensible critique is narrower. When you issue a systemctl command, you are not issuing a simple signal or writing to a filesystem. You are sending a structured D-Bus message. This means systemctl requires the D-Bus daemon or socket to be functional. It means that auditing system administration requires auditing D-Bus policy files as well as unit files. It means that in minimal or embedded environments, the D-Bus message bus is overhead that alternatives like runit simply do not impose.

In runit, sv up nginx writes to a specific socket path. The interface is minimal, documented in a man page you can read in ten minutes, and has no runtime dependencies beyond a running runsv process. The additional complexity that D-Bus introduces is not catastrophic. But it is real, and it is unnecessary for the core function of service management.

The most important thing to understand about systemd's spread is that it was not simply adopted because it was better. It was adopted partly because of a deliberate strategy of dependency creation.

GNOME 3, beginning around 2012, made logind — systemd's login session manager — a hard dependency. The practical effect was that distributions shipping GNOME 3 were effectively required to ship systemd, because logind provided session tracking, multi-seat support, and power management integration that GNOME relied upon.

logind was not separately packaged. It was part of systemd. There was no supported path to run GNOME 3 with logind but without systemd. Some distributions — notably Gentoo and then Devuan — built compatibility layers: elogind, a fork of logind that can run without the rest of systemd. This was significant engineering work, necessitated by a dependency that had been made intentionally tight.

The result is that today, running a modern desktop environment without systemd requires maintaining compatibility shims for components that were deliberately extracted from a separable subsystem and welded into a monolithic release. This is not an accident of technical necessity. It is a consequence of architectural choices that had the effect of making alternatives more expensive to maintain.

Fedora adopted systemd in May 2011. Fedora is Red Hat's upstream experimental distribution. Red Hat employs Lennart Poettering. This is not a conspiracy; it is a corporate development model.

Arch Linux adopted systemd in October 2012. Arch developers debated the choice and concluded it was faster and had more features, and that maintaining SysVinit compatibility was not worth the effort. This was a genuine evaluation, not merely following Red Hat.

Debian's adoption was the critical moment. The Debian Technical Committee voted in February 2014 to adopt systemd as the default init for Debian Jessie. The vote was tied at 4 to 4 before the casting vote was applied. This was not a consensus. It was a narrow majority on the question that would shape the default init system for the distribution that underlies Ubuntu, Linux Mint, and dozens of other derivatives.

After that, the remainder followed. Not because every distribution independently evaluated systemd and concluded it was the best choice, but because the ecosystem had shifted. Upstream projects began writing systemd unit files and stopping maintenance of SysVinit scripts. Software documentation began assuming systemd. The gravity well became self-reinforcing.

The most effective rebuttal to the claim that systemd won because it was best is to point at systems running without it.

runit is a process supervision system by Gerrit Pape, based on daemontools by D.J. Bernstein. It is fast, small, and has accumulated one CVE in its entire existence. Its codebase is a few thousand lines of C. An administrator can read it in a weekend. It supervises processes, manages dependencies, restarts failed services. It does not manage DNS. It does not encrypt home directories. Void Linux ships runit. Void Linux works, on servers, laptops, and embedded hardware. The absence of systemd has not caused it to collapse.

OpenRC is used by Gentoo and Alpine Linux. Alpine's container images, based on musl libc and BusyBox init, are measurably smaller and faster than equivalent Debian-based images — a fact relevant to anyone who operates container infrastructure at scale.

s6, dinit, GNU Shepherd, and sinit all represent working alternatives at different points on the complexity spectrum. They run real systems. The claim that systemd is technically necessary is empirically false, demonstrable by inspection of running production systems today.

systemd is a Red Hat project. It was written by Red Hat employees. It was adopted first in Fedora, Red Hat's upstream. Its adoption in RHEL made it the de facto standard for enterprise Linux. The GNOME dependency on logind accelerated its spread to desktop distributions. The result is that the init system of most Linux distributions was built, directed, and stewarded by a subsidiary of IBM.

The biography of its primary author maps the concentration of control precisely. Lennart Poettering worked at Red Hat from 2008 to 2022, creating and developing systemd throughout. In 2022 he joined Microsoft, continuing to lead systemd development from inside the company that spent the 1990s and 2000s characterising Linux as a cancer, funding SCO litigation, and lobbying against open source procurement in government. In January 2026, Poettering left Microsoft to co-found Amutable, a Berlin-based startup focused on cryptographically verifiable integrity for Linux systems.

What can be said is that the development of systemd has never been governed by the Linux community at large. It has been governed by whoever employs Lennart Poettering. That is a governance model, whether or not it was ever consciously chosen as one. And it is a governance model that no single person or team in the Unix tradition ever exercised over an entire ecosystem.

Boot speed was the headline feature. systemd parallelises service startup, uses socket activation to start services lazily, and tracks dependencies to avoid unnecessary waits. These are real techniques that produce real improvements on real hardware.

They are also improvements that were available before systemd, through Upstart and through careful SysVinit configuration. More importantly, the environments that care most about boot time — large-scale cloud infrastructure, embedded systems, containers — are precisely the environments where systemd's overhead is least welcome and its alternatives most actively used.

On the server side, the persistent argument that systemd improves reliability through better dependency management has been challenged by the lived experience of administrators who have watched cascading systemd failures bring down services in ways that the older, simpler model would have contained. A service that fails to start in SysVinit fails. A service that fails to start in systemd can block all services that depend on it, trigger timeout cascades, and leave the system in a state that requires forensic analysis of the journal to understand. The complexity is not an accident of implementation. It is a structural property of the architecture.

systemd is not evil. Lennart Poettering is not a villain. The people who work on systemd are not saboteurs. This is important to state clearly, because the alternative init community has sometimes failed to say it, and that failure has made it easy to dismiss the technical arguments as personality conflicts.

The problem with systemd is architectural, political, and cultural simultaneously, and it must be addressed on all three dimensions to be taken seriously.

Architecturally, it violates the principles that have made Unix-derived systems robust for fifty years. It concentrates scope. It couples components via shared libraries and a shared release cycle. It makes PID 1 reachable via D-Bus. The CVE record does not indict the developers. It maps the surface area. A DNS resolver will have DNS vulnerabilities. A DHCP client will have DHCP vulnerabilities. runit and OpenRC have neither, and their combined CVE history across two decades fits in a paragraph.

Politically, it represents a concentration of control over critical Linux infrastructure that was acquired not through formal governance but through dependency engineering and ecosystem capture. The Debian Technical Committee vote that sealed systemd's dominance over the Debian family was 4 to 4 before the casting vote. That is not a mandate. That is a coin toss that reshaped the landscape for a decade.

Culturally, it has normalised a style of Linux development where the answer to every problem is a new systemd component, where "just use systemd" is the accepted response to infrastructure questions, and where the cognitive overhead of understanding one's own init system has grown from "read a few shell scripts" to "understand a codebase that exceeded 1.7 million lines by 2022, with its own binary formats, its own IPC protocol, its own DNS resolver, its own boot specification, and its own institutional politics."

The distributions that have refused systemd — Void Linux, Gentoo, Alpine, Devuan, Artix — are not running on legacy infrastructure. They run current software on current hardware. They do so with init systems that are smaller, faster, more auditable, and architecturally honest about what an init system should be.