Why systemd is a problem for embedded Linux

Original Article ↗ Hacker News Discussion ↗

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.