I have completed an initial new port of systemd to musl. This patch set does not share much in common with the existing OpenEmbedded patchset. I wanted to make a fully updated patch series targetin…

I have completed an initial new port of systemd to musl. This patch set does not share much in common with the existing OpenEmbedded patchset. I wanted to make a fully updated patch series targeting more current releases of systemd and musl, taking advantage of the latest features and updates in both. I also took a focus on writing patches that could be sent for consideration of inclusion upstream.

The final result is a system that appears to be surprisingly reliable considering the newness of the port, and very fast to boot.

…

And that is how I became the first person alive to see systemd passing its entire test suite on a big-endian 64-bit PowerPC musl libc system.

…

While the system works really well, and boots in 1/3rd the time of OpenRC on the same system, it isn’t ready for prime time just yet.

…

There aren’t any service unit files written or packaged yet, other than OpenSSH and utmps. We are working with our sponsor on an effort to add -systemd split packages to any of the packages with -openrc splits. We should be able to rely on upstream units where present, and lean on Gentoo and Fedora’s systemd experts to have good base files to reference when needed. I’ve already landed support for this in abuild.

This work is part of Adélie Linux

  • khorovodoved@lemm.ee
    63·
    2 months ago

    While I do appreciate the effort, I cannot understand, who in their right mind would use musl and systemd together. For what purpose? If a person was already willing to manage a musl system, why wouldn’t he also prefer sysVinit or runit or whatever?

    • tiny@midwest.socialEnglish
      151·
      2 months ago

      I want to try alpine out but the lack of systemd support is a blocker since I don’t want to add openrc support to all my Ansible playbooks that rely on systemd services and timers

    • Magiilaro@feddit.org
      7·
      2 months ago

      Maybe because that person uses systemd everywhere else and just doesn’t want the overhead of maintaining two different init systems.

    • intelisense@lemm.ee
      4·
      2 months ago

      My understanding is that it boots faster. That’s a nice thing to have on a container that spins up on demand.

      • khorovodoved@lemm.ee
        5·
        2 months ago

        It boots faster than openRC (which is painfully slow). But runit is a lot faster than systemd, and there are init systems even faster than runit. And they all already work with musl. There is even dinit system specifically designed for containers.

      • corsicanguppy@lemmy.caEnglish
        1·
        2 months ago

        My understanding is that it boots faster.

        I tested this with EL6 and EL7. There was no discernible difference. It was all theories and brochureware.

    • PureTryOut@lemmy.kde.social
      4·
      2 months ago

      The reasons for choosing Musl over glibc are largely unrelated for choosing a service manager. You can want one without the other just fine.

    • corsicanguppy@lemmy.caEnglish
      28·
      2 months ago

      I can’t understand anyone wanting that hot mess that is systemd anywhere. I’m only glad lennart went to microsoft so the pruning can begin.

      • Magiilaro@feddit.org
        4·
        2 months ago

        There is no indication that anyone will be pruning systemd from distros in the near or far future. Systemd is here to stay and if anything it will only spread into more and more places as can be seen with projects like this.