Why systemd Sucks

Introduction

systemd is one of the most widely used init systems in modern Linux distributions. While it offers a wide range of features, it has also been the subject of strong criticism from parts of the Unix and Linux community. This document outlines the most common arguments against systemd, particularly from the perspective of users who value simplicity, modularity, and adherence to traditional Unix design principles.

Violates the Unix Philosophy

One of the most common criticisms is that systemd does not follow the classic Unix philosophy: “Do one thing and do it well.”

Instead of being a simple init system responsible only for starting and managing services, systemd has grown into a large suite of tightly integrated components. These include:

• Service management
• Logging (journald)
• Device management
• Network configuration
• Time synchronization
• Login/session management

This integration creates a monolithic structure where many unrelated responsibilities are bundled into a single project.

Complexity and Size

systemd is significantly more complex than traditional init systems such as SysVinit or OpenRC. This complexity introduces several issues:

• Harder to understand and debug
• Steeper learning curve
• Increased attack surface
• More difficult maintenance

For users who prefer minimalism and transparency, systemd can feel overwhelming.

Tight Coupling and Lack of Modularity

Traditional Unix systems are composed of many small, independent tools that can be combined flexibly. systemd, however, tightly integrates its components, making it difficult to replace individual parts.

For example:

• journald replaces traditional syslog systems
• systemd-networkd replaces separate networking tools

This reduces flexibility and forces users into a specific ecosystem.

Binary Logging (journald)

systemd uses a binary logging format via journald instead of plain text logs. Critics argue that this has several downsides:

• Logs are not easily readable with standard tools like cat or grep
• Corruption of binary logs can make them unreadable
• Requires special tools (journalctl) to access logs

Plain text logs are considered more robust, transparent, and portable.

Reduced Transparency

With traditional init systems, service behavior is often defined by simple shell scripts that are easy to inspect and modify.

systemd uses declarative unit files, which are concise but abstract away execution details. This can make it harder to understand what exactly is happening during service startup or failure.

Scope Creep

systemd has expanded far beyond its original purpose as an init system. Over time, it has taken over responsibilities that were previously handled by separate tools.

Examples include:

• Hostname management
• DNS resolution
• Container management

This scope creep is often cited as a key reason why systemd is seen as overly invasive.

Portability Concerns

systemd is tightly coupled to the Linux kernel and relies on Linux-specific features such as cgroups.

This makes it unsuitable for non-Linux Unix-like systems and reduces portability compared to simpler init systems.

Centralization of Control

systemd consolidates many core system functions under one project. Critics argue that this centralization:

• Reduces diversity in the ecosystem
• Increases dependency on a single project
• Creates a single point of failure

Debugging Difficulty

When something goes wrong in a systemd-based system, debugging can be more complex due to:

• Interdependencies between components
• Non-obvious execution flow
• Reliance on systemd-specific tools

This contrasts with traditional systems where issues can often be traced through simple scripts and logs.

Cultural and Philosophical Concerns

Beyond technical arguments, some criticism is rooted in philosophy:

• Preference for simplicity over feature-rich design
• Resistance to large, dominant projects
• Desire to preserve traditional Unix design patterns

For these users, systemd represents a shift away from the original spirit of Unix.

Comparison with Alternative Init Systems

To better understand the criticism of systemd, it is useful to compare it with other init systems that follow different design philosophies.

OpenRC

OpenRC is used by distributions such as Gentoo and Alpine Linux. It aims to provide a simple and flexible init system while maintaining compatibility with traditional Unix concepts.

Key characteristics:

• Uses plain shell scripts for services
• Focuses strictly on service management
• Lightweight and easy to understand
• Does not enforce a tightly integrated ecosystem

Compared to systemd, OpenRC is significantly smaller and more transparent, making it attractive for users who prefer simplicity and control.

runit

runit is a minimalistic init system designed for speed and simplicity.

Key characteristics:

• Extremely small codebase
• Fast service startup and supervision
• Uses simple directory-based service definitions
• Strong focus on reliability and determinism

Unlike systemd, runit does not attempt to manage unrelated subsystems. It strictly handles process supervision, which aligns closely with the Unix philosophy.

s6

s6 is a more advanced supervision suite that builds on the same minimalistic ideas as runit but offers more flexibility and features.

Key characteristics:

• Modular design with separate components
• Very fine-grained control over service dependencies
• Emphasis on correctness and robustness
• Designed for scripting and composability

s6 can be more complex than runit, but its complexity comes from composability rather than centralization. It allows users to build exactly the system they need without enforcing a monolithic design.

Summary of Differences

Overall, alternatives like OpenRC, runit, and s6 emphasize simplicity, modularity, and transparency. In contrast, systemd prioritizes integration and feature completeness, which leads to fundamentally different trade-offs.

Technical Deep Dive

This section provides a more technical comparison of how systemd and alternative init systems operate internally, with a critical perspective favoring simplicity, transparency, and robustness.

Dependency Handling

systemd uses a declarative dependency model defined in unit files. Services specify dependencies such as After=, Requires=, or Wants=. systemd then computes a dependency graph and executes units in parallel where possible.

While this sounds powerful, it introduces significant complexity:

• Non-trivial dependency semantics that are easy to misconfigure
• Execution order can become opaque and difficult to debug
• Hidden behavior due to implicit dependencies

In contrast:

• OpenRC uses simple, readable shell-based dependencies
• runit avoids complex dependency graphs entirely
• s6 provides explicit dependency handling without hiding logic

These approaches are easier to reason about and align better with predictable system behavior.

Service Supervision

systemd integrates supervision directly into PID 1 and relies heavily on cgroups.

• Centralized control
• Complex internal logic

This violates the principle of keeping PID 1 minimal and reliable. A failure or bug in systemd can affect the entire system.

runit and s6 take a fundamentally cleaner approach:

• Each service has its own small supervisor
• Failures are isolated
• Restart behavior is simple and deterministic

This model is widely regarded as more robust and closer to the Unix philosophy.

Logging Architecture

systemd uses journald with a binary log format.

While it offers structured logging:

• It breaks compatibility with standard Unix tools
• Requires journalctl instead of simple tools like grep or cat
• Binary logs are harder to recover if corrupted

Traditional logging used by alternatives:

• Plain text logs
• Fully compatible with existing Unix tooling
• Easy to inspect, process, and recover

From a Unix perspective, plain text logs are clearly superior due to their simplicity and transparency.

Boot Process

systemd aggressively parallelizes boot using dependency graphs and socket activation.

Although this can reduce boot time:

• It introduces hidden complexity
• Makes system behavior less predictable
• Encourages tightly coupled service design

Alternatives:

• OpenRC: simple parallelization without excessive abstraction
• runit: deterministic staged boot process
• s6: explicit and customizable boot pipeline

These approaches may be slightly less optimized but are far easier to understand and debug.

Configuration Model

systemd relies on declarative unit files.

• Abstract and compact
• But often obscure actual execution logic

Alternatives use scripts:

• Fully transparent behavior
• Easy to inspect and modify
• No hidden execution layers

For experienced administrators, explicit scripting is often preferable to opaque declarative systems.

Resource Management

systemd integrates tightly with Linux cgroups for resource control.

While powerful, this introduces:

• Additional complexity
• Tight coupling to Linux-specific features
• Reduced portability

Alternatives deliberately avoid this scope creep and rely on external tools when needed, preserving modularity.

Failure Handling

systemd provides advanced failure handling with restart policies and integrated diagnostics.

However:

• Behavior can be difficult to predict
• Debugging requires systemd-specific knowledge

runit and s6:

• Use simple supervision loops
• Restart services immediately and predictably
• Easier to debug due to minimal abstraction

In practice, simplicity often leads to greater reliability.

Overall Technical Assessment

From a technical standpoint, systemd prioritizes feature integration and automation at the cost of clarity and modularity. While it solves many problems in a unified way, it does so by centralizing complexity into a single, large codebase.

Alternatives like OpenRC, runit, and s6 take the opposite approach:

• Keep components small and focused
• Favor explicit behavior over abstraction
• Maintain compatibility with traditional Unix tools

For users who value control, predictability, and long-term maintainability, these qualities make the alternatives not just different—but technically preferable.

Failure Scenarios and Component Critique

This section highlights concrete real-world failure scenarios and examines specific systemd components that are often criticized.

PID 1 Risks

In Unix-like systems, PID 1 is the most critical process. It must remain as small, stable, and predictable as possible.

systemd violates this principle by embedding a large amount of functionality directly into PID 1:

• Service management
• Dependency resolution
• Logging hooks
• cgroup interaction

Implications:

• A bug in any of these subsystems can compromise PID 1
• Debugging PID 1 failures is extremely difficult
• In worst cases, system instability or kernel panic-like states can occur

In contrast:

• runit and s6 keep PID 1 minimal
• Most logic runs in separate processes
• Failures are isolated and do not cascade into total system failure

This design difference is one of the strongest technical arguments against systemd.

journald Critique

journald replaces traditional syslog with a binary logging system.

Common real-world issues:

• Corrupted journal files can become unreadable
• Recovery without journalctl is difficult or impossible
• Logs are not directly accessible in rescue environments without systemd tools

Operational drawbacks:

• Breaks standard Unix workflows (grep, tail, awk pipelines)
• Adds an additional layer of tooling dependency
• Makes log portability and long-term archival harder

Even though journald supports exporting logs to text, this adds unnecessary complexity compared to native plain-text logging.

systemd-networkd Critique

systemd-networkd attempts to replace traditional networking tools.

Problems observed in practice:

• Limited flexibility compared to mature tools like ifupdown or NetworkManager
• Configuration is less intuitive for complex setups
• Debugging network issues requires systemd-specific knowledge

Additionally:

• Tight integration with systemd makes it harder to replace cleanly
• Failures in network configuration can be harder to isolate

Many administrators prefer dedicated networking tools that follow established Unix conventions.

Real Failure Scenario: Logging Failure

Scenario:

• journald becomes corrupted or fails to start

Impact:

• System logs may become inaccessible
• Debugging other failing services becomes significantly harder
• Requires systemd-specific recovery steps

With traditional syslog:

• Logs remain plain text
• Even partial corruption does not make the entire log unreadable

Real Failure Scenario: Dependency Deadlock

Scenario:

• Misconfigured unit dependencies create circular or conflicting requirements

Impact:

• Services fail to start
• Boot process may hang or degrade unpredictably
• Error messages are often non-trivial to interpret

Simpler systems:

• Either avoid complex dependencies (runit)
• Or make them explicit and script-visible (OpenRC, s6)

This reduces the likelihood and impact of such failures.

Real Failure Scenario: PID 1 Overload

Scenario:

• High system load combined with complex service interactions

Impact:

• PID 1 becomes a bottleneck
• Delays in service management
• Potential cascading failures

In minimal init systems:

• Work is distributed across small processes
• No single complex control point exists

Overall Assessment of Components

systemd components such as journald and networkd aim to replace well-established Unix tools with integrated alternatives. While this can provide convenience, it often comes at the cost of:

• Reduced transparency
• Increased complexity
• Higher coupling between system components

In contrast, traditional tools:

• Are simpler and battle-tested
• Can be replaced independently
• Follow well-understood Unix patterns

From a reliability and maintainability standpoint, the traditional approach remains superior for many use cases.

Conclusion

systemd provides powerful features and has become the standard in many Linux distributions. However, for users who value simplicity, modularity, and strict adherence to the Unix philosophy, systemd introduces trade-offs that are difficult to accept.

Whether systemd is “good” or “bad” ultimately depends on individual priorities. This document highlights the reasons why some users choose to avoid it and prefer alternative init systems.

Links

• No systemd
• The world after systemd
• I Hate Systemd
• suckless.org on systemd
• Broken by design: systemd
• Without systemd
• 15 Systemd-Free Linux Distributions
• OpenRC
• runit
• s6
• s6-linux-init
• sinit - suckless init
• German Forum systemdfree

Comments