Porting systemd to musl Libc-powered Linux
Porting the systemd init system to Linux distributions built on the musl C library is rekindling long‑running debates about performance, compatibility and ecosystem control. Commenters weigh the benefits of systemd’s fast, highly featured, and widely supported service management—especially for parallel startup, security sandboxing and complex networking—against concerns over complexity, past reliability issues, and its growing influence on traditionally minimalist musl‑based distros like Alpine. The thread also touches on musl vs. glibc trade‑offs, containerized application formats, and the needs of embedded and serverless environments where boot time and binary size are critical.
Porting systemd to musl & upstreaming
- Multiple PRs to support musl have already been merged; likelihood of full upstreaming is described as high.
- Many patches fix assumptions where glibc exposes extra symbols or APIs and musl does not.
- Prior debates show musl maintainers dislike copying non‑POSIX “glibc‑isms”, while systemd maintainers don’t want to re‑implement glibc extensions they rely on.
- Some suggest a compatibility libc or headers to provide glibc APIs on top of musl; existing gcompat is noted as binary‑only, not for compiling.
- One controversial API is
malloc_info(XML dump of allocator state) used only for debugging; critics call it a bad interface and resent that making it optional “can’t be upstreamed.”
Boot performance & init systems
- Blog claims systemd boots in ~1/3 the time of OpenRC; some find this suspiciously large but note OpenRC’s parallel startup is disabled by default and documented as unstable.
- Several argue boot time doesn’t matter for always‑on servers/laptops, but others stress its importance for embedded, serverless, microVMs, and post‑S3 laptops.
- Some report OpenRC (or even a minimal inittab) already boots “fast enough”; others say OpenRC is “known slow” and that systemd wins on parallelization.
Systemd benefits vs drawbacks
- Pro‑systemd points:
- Huge ecosystem support, wide testing, and heavy sponsorship.
- Big win for distro maintainers vs duct‑taped sysvinit.
- Rich features: socket activation, user services, declarative sandboxing (namespaces, syscall filtering), tmpfiles, TPM secrets, logind, networkd.
- Critiques:
- “Good ideas, bad implementation” and poor UX (confusing defaults, unhelpful error messages, sparse docs).
- journald seen by some as slow, resource‑heavy, single‑bucket logging with awkward defaults and binary format; others report it performing fine even on weak hardware.
- Past high‑impact bugs are cited (system‑bricking issues, efivarfs RW, DHCP failures, coupling into OpenSSH).
- Some view systemd as work‑only “big contraption,” preferring simpler stacks at home.
Alpine, OpenRC, and ecosystem tensions
- Alpine’s musl/busybox/OpenRC stack is praised for minimalism, good battery life, and low background activity.
- Strong resistance to systemd entering Alpine or its ecosystem; fear of packages eventually requiring systemd.
- Counter‑argument: distros voluntarily chose systemd because alternatives are slower, less featureful, and harder to integrate; forking to avoid systemd is possible but costly, so “choice” feels constrained.
musl vs glibc performance & tradeoffs
- Shared links show mostly small performance differences, with one outlier reporting musl much slower for multithreaded allocation.
- Some believe musl’s malloc and overall performance are weaker; others note glibc’s allocator is hardly ideal either.
- General view: musl prioritizes size and simplicity, glibc prioritizes features and speed; you usually trade one for the other.