Systemd through the eyes of a musl distribution maintainer

Original Article ↗ Hacker News Discussion ↗

Linux’s move toward systemd as the dominant init and service manager is praised for raising the bar in reliability, dependency handling, and modern features, but criticized for creating a fragile monoculture and entangling many unrelated system functions under one umbrella. Commenters highlight concrete pain points — from binary logging and systemd-resolved quirks to complexity, security surface area, and poor fit for small or embedded setups — while acknowledging that its tight integration often “just works” in dynamic desktop and enterprise environments. Alternatives like OpenRC, s6, and nosh are mentioned, yet many note that ecosystem dependencies and project governance choices make it hard for competing approaches to gain real traction.

Monoculture, governance, and competition

  • Many agree systemd solved real problems (boot parallelism, supervision, dependencies), but worry its dominance creates a monoculture that blocks alternatives and forces bug‑compatibility.
  • Others argue the pre‑systemd “multi‑culture” was chaotic and inferior; systemd simply out‑delivered competitors.
  • Some see the way distros made systemd effectively mandatory (especially in Debian) as a governance failure and source of lasting resentment.
  • A few think supporting multiple init systems is feasible but requires resources and interest; Gentoo is cited as proof.

Scope of PID 1 and architecture

  • Debate over what PID 1 “should” do: minimal first userspace program vs central orchestrator for processes, mounts, networking, and more.
  • Some defend putting process management in PID 1 for strong guarantees; others see feature accretion (NVMe‑over‑TCP, etc.) as “kitchen sink” bloat.

Service management and admin experience

  • Many admins praise systemd for standardized tooling, dependencies between services/mounts/sockets, easier privilege dropping, and journald’s per‑unit log aggregation.
  • Others report pain: timeouts during boot/shutdown, difficulty interrupting failing units, and confusing per‑user instances (linger, loginctl).
  • Socket activation and inetd‑style designs divide opinion: some see central listeners as safer and simpler; others view super‑servers as anti‑pattern and DoS risk.

Logging (journald) and complexity

  • Binary journals with rich metadata are seen as powerful for centralized logging, but:
    • Harder to use with traditional text tools (grep/rsync).
    • Slower and sometimes corrupt, leading to claims they’re “reinventing a database.”
  • Systemd’s many unit types and search paths improve flexibility but hurt “locality of behavior,” making systems harder to reason about.

DNS and networking (systemd‑resolved)

  • resolved gets significant criticism: DNSSEC issues, fragile behavior in non‑trivial setups, and confusion around its production‑readiness.
  • Supporters emphasize features like split DNS tied to interfaces/VPNs and tight integration with other systemd components; critics note similar setups possible with dnsmasq, though with more glue.

Alternatives and rewrites

  • Various alternatives are mentioned: OpenRC, s6/66suite, runit, dinit, nosh, and Rust re‑implementations aiming for partial systemd compatibility.
  • Some believe a “PipeWire‑style” cleaner successor might eventually emerge, but fear systemd’s pace and ecosystem lock‑in make that difficult today.