Why systemd is a problem for embedded Linux

Original Article ↗ Hacker News Discussion ↗

Systemd’s suitability for embedded Linux is sharply contested, with critics arguing it is too heavy, tightly coupled and desktop‑oriented for devices constrained by RAM, flash size, boot time and OTA update budgets. Supporters counter that a minimal systemd can run in just a few megabytes, brings robust service management, logging and dependency handling, and simplifies life for distributors and administrators. The exchange highlights a broader tension between monolithic, standardizing platforms and modular “Unix philosophy” stacks built from lighter inits, custom tooling, or even non-Linux RTOSes for deeply embedded use.

Scope and adoption of systemd

  • Many argue systemd’s primary win is on servers and general-purpose desktops: dependency-aware service management, parallel boot, standardized logging, and unified tooling across distros.
  • Several point out that adoption was driven by sysadmins’ needs and distro maintainers’ convenience, not just “desktop integration.”
  • Others see political and vendor influence (especially large commercial Linux vendors) as a major driver and call the adoption “forced” rather than organic.

Embedded constraints: RAM, flash, boot time

  • One camp says modern embedded Linux devices often ship with ≥512 MB–1 GB RAM, where systemd’s real footprint (~3–8 MB RAM, a couple MB on disk) is negligible.
  • Another stresses that many cost-sensitive products still ship with 16–256 MB RAM and tight flash/OTA budgets; a few extra MB for systemd (and dbus) are a real cost and can lengthen boot times.
  • Economic arguments recur: saving even ~$0.10–$2.50 per unit in RAM/flash can matter at million‑unit scale; others counter that small RAM size deltas at low capacities are now cheap.

Technical benefits cited

  • Faster, more predictable boot on many systems; out‑of‑the‑box parallelization.
  • Unified service management (restart, watchdogs, dependencies, device/network awareness).
  • Integrated but optional components (journald, networkd, resolved, timers, timesyncd) can replace ad‑hoc scripts and cron in some deployments.
  • Some embedded teams report good results running systemd on 128 MB–512 MB boards and value reduced fiddling.

Technical issues and criticisms

  • Complaints about long or opaque shutdown/boot timeouts, non‑deterministic boot ordering in complex setups, and “fiddly” configuration when deviating from defaults.
  • Journald is seen by some as fragile (corruption, gaps, rotation issues) and often incomplete vs traditional file/syslog setups.
  • systemd is viewed as monolithic “epoxy”: logging, init, udev, login, DNS, time sync, etc., are tightly coupled and hard to swap out; this is framed as “anti‑Unix‑philosophy” and creating de‑facto lock‑in.
  • Portability concerns: heavy reliance on glibc/gcc extensions and weaker support with musl/LLVM in some embedded stacks.
  • Some report yearly “weird” failures or undocumented behaviors, and say maintainers can be dismissive of “unsupported” use cases.

Alternatives and ecosystems

  • Non‑systemd options mentioned: OpenWRT’s procd, BusyBox init + mdev, OpenRC, runit, s6, Gentoo, Devuan, Void, Alpine, Chimera, Yocto/Buildroot, BSDs, and non‑Linux RTOSes (Zephyr, FreeRTOS).
  • Consensus: for very small or highly cost‑constrained devices, minimal init + BusyBox/RTOS is often preferable; for larger embedded or server‑class devices, systemd can be attractive if its trade‑offs are acceptable.