Systemd has merged experimental support for musl libc, an implementation of the C standard library built on top of the Linux system call API, marking a notable shift in compatibility across the Linux landscape. And if you’re wondering why this is so important, let me explain.
For years, systemd and musl occupied separate worlds: systemd required glibc, while musl-based distributions relied on alternative init systems and service managers.
In other words, distros using musl libc could not run systemd without extensive patching—or at all. So, all musl-based distros were effectively systemd-free (they used OpenRC, s6, runit, dinit, etc.).
With this change, however, things have the potential to change. Systemd now builds successfully against musl in the upstream CI, thanks to the project’s inclusion of the necessary compatibility code.
Yu Watanabe, Red Hat Senior Software Engineer and systemd developer, commented:
“I’ll go ahead and merge this. It all does seem fairly fragile, so I’m a bit worried that maintenance will be a problem. But the only way to verify this is to merge this and let people play with it.
I spent some time repeating the build with musl locally on Fedora, and that part works well enough. But I couldn’t get the tests to run without a container. That part is a bit annoying — we really need to have a simple local workflow for development. But at least compilation works, so maybe it won’t be so bad.
Compilation and unit tests pass in the CI, which is good enough for now.”
As I mentioned earlier, this development has the potential for direct implications for distributions built on musl. Alpine Linux, Chimera Linux, postmarketOS, and other lightweight or embedded systems can (eventually) begin experimenting with systemd components.
And although none of these projects have announced plans to adopt it — and most likely won’t — upstream support removes a long-standing barrier that previously made these experiments impractical.
The change also matters for developers targeting mobile, IoT, or container-focused platforms. Musl offers a small and predictable libc, while systemd provides a comprehensive suite of services, logging, cgroup, and network components. Being able to combine the two expands the range of configurations available for specialized appliances and minimal cloud images.
At this stage, systemd’s maintainers consider the support fragile and expect issues to surface as more users test it. However, integrating musl into the project’s CI ensures future regressions are visible to upstream developers rather than left to downstream patching. This makes musl a first-class consideration in systemd’s build process for the first time.
For more information, see the PR on GitHub.
Well, well! Isn’t THIS a horrible step backward!