Init Systems: Looking at systemd and Shepherd

Sometime ago I explored the FOSDEM 2025 conference’s vast video archive, and I quite liked a couple of videos on init systems.

An init system is a computer system that’s responsible for starting and managing all programs on a given machine (my naive definition).

In my mind, one of the most impressive init systems was the Apollo Guidance Computer. This system was aboard the Apollo 11 mission that landed on the moon, and it supported up to seven simultaneous running programs. It was a true technical marvel built by programmer Margareth Hamilton, and during the moon lander’s descent on the moon its failsafe systems kicked in to protect the astronauts due to constrained system resources.

systemd #

At FOSDEM 2025 there was a talk named 14 Years of systemd, presented by systemd core contributor Lennart Poettering.

Over the years more and more Linux distributions have replaced their init systems with systemd. This has not been without controversy, where some Linux folks voting with their feet and launching Linux distributions with alternatives to systemd.

It was interesting to hear how systemd started from humble beginnings with Lennart and Kay Sievers hashing out some ideas on a flight home from Linux Plumbers conference in 2009. When making systemd they worked hard to learn from existing approaches to init systems. For example, Lennart notes how systemd was inspired by Apple’s launchd which featured the concept of socket activation (I also find socket activation very cool). Additionally, Lennart also explained how systemd was influenced by the UNIX approach.

I emphathize with the systemd critics who feel that systemd has come to dominate the Linux landscape, as well as dominate the inner machinations of the individual distributions.

When I work with systemd, piecing together services, and try to harden them for security, I’m oftentimes overwhelmed by the amount of configuration options. While I need to cover all possible weak points, an attacker only needs to find and exploit but one vulnerability…

To rescue us we have the command systemd-analyze security which gives an overview of what services are in need of security tightening. And you can call systemctl edit $SERVICE_NAME to try and harden the service using a cornucopia of systemd options for the execution environment. I’ve hardened services a couple of times using this approach, but there’s always a nagging feeling that I might have misread something in systemd’s exhaustive documentation.

Anyhow, I have a lot of respect for systemd’s technical prowess. This talk gave me a better perspective on systemd.

shepherd #

In the room for Declarative and Minimalistic Computing, there was a talk named The Shepherd: Minimalism in PID 1, given by core contributor Ludovic Courtès.

The Shepherd is an init system written in Guile scheme, which was first announced in 2003 under the name dnd (daemons-managing-demons). It was later relaunched as Shepherd in 2013, and reached a 1.0 release december 2024. Guix is a Linux distribution, which employs Shepherd as its init system.

In the talk Courtès demoed various herd commands for interacting with Shepherd’s services. Also, he showed how it’s possible to connect a REPL to the Shepherd’s services, and even Shepherd itself. This lets you hack on your machine’s init system while it’s running. Such debugability and “liveness” to programming is fascinating to see. There’s also a test suite, and virtual machine setup to let you develop Shepherd without tampering with the Shepherd instance running on your machine.

All in all, it’s cool to see an init system written in a high-level language such as Guile. Courtès noted that it’s not all rainbows to work with it, and he showed some of the pitfalls such as one might write a service that hangs indefinitely or cause a memory leak. And while systemd has a lot more features than Shepherd, personally I think Shepherd looks more approachable as a potential contributor.