The earlier systemd guide in this series mentioned that criticism of systemd exists without fully exploring what the actual alternatives look like in practice. Understanding systemd vs OpenRC vs runit rounds out that picture, useful both for real technical understanding and for anyone considering a distribution that deliberately doesn’t use systemd, like Alpine Linux or Void Linux.
What an Init System Actually Does
Every Linux system needs a first process (PID 1) that starts when the kernel finishes booting, responsible for launching every other system service, managing their dependencies, and handling process supervision throughout the system’s uptime. The init system is this foundational layer, and while systemd has become the overwhelming default across mainstream distributions, it isn’t the only option.
systemd: The Mainstream Default
As covered in the earlier dedicated guide, systemd handles far more than traditional init systems historically did — service management, logging (via journalctl), device management, and more, all consolidated into one large, tightly-integrated project. This is precisely the design choice critics object to, arguing it violates the traditional Unix philosophy of small, focused, independently-replaceable tools.
OpenRC: A Traditional Alternative with Modern Conveniences
OpenRC is the default init system on Gentoo and Alpine Linux, offering dependency-based service management (like systemd) while remaining a considerably smaller, more traditional Unix-style tool rather than systemd’s broader, more consolidated scope. It works alongside traditional init scripts rather than replacing the entire concept, striking a middle ground between old-style SysVinit and systemd’s more expansive approach.
Basic OpenRC commands:
rc-service nginx start
rc-service nginx stop
rc-update add nginx defaultNotice the closer resemblance to traditional Unix service management compared to systemd’s systemctl approach.
runit: Minimalism as the Core Design Principle
runit takes minimalism further still, used as the default init system on Void Linux and available as an alternative on several other distributions. Its entire design centers on being small, auditable, and doing exactly one thing — process supervision — without systemd’s broader scope covering logging, networking, and device management within the same project.
Basic runit service management:
sv start nginx
sv stop nginx
sv status nginxrunit’s service definitions are simple directories containing a run script, considerably more transparent and easy to fully understand line-by-line compared to systemd’s more complex unit file system with its many possible directives.
Comparing Logging Approaches
systemd’s integrated journalctl () provides structured, centrally-queryable logs by default. OpenRC and runit both rely on more traditional approaches — typically syslog or dedicated logging tools like svlogd (runit’s companion logging tool) — requiring separate configuration to achieve similar centralized log querying capability that systemd provides natively.
Which Distributions Use Which
- systemd – the overwhelming majority: Ubuntu, Debian, Fedora, RHEL/AlmaLinux, and most mainstream distributions covered throughout this series
- OpenRC – Gentoo (its origin), Alpine Linux (relevant to the Alpine container base image guide covered earlier)
- runit – Void Linux, and available as an alternative init on some other distributions
Why This Matters Beyond Philosophical Preference
Beyond the ideological Unix philosophy debate, the practical impact shows up specifically if you’re running Alpine-based containers — Alpine’s OpenRC-based init approach differs significantly from systemd-based distributions’ service management, worth understanding if you ever need to debug service startup issues specifically within an Alpine container rather than assuming systemd’s commands and concepts apply identically everywhere.
Should You Choose a Non-systemd Distribution for Your Homelab?
For most homelab purposes, systemd’s dominance means significantly more documentation, community support, and straightforward compatibility with guides (including most of this series) that assume systemd’s tooling. Choosing OpenRC or runit-based distributions specifically for a homelab server is a deliberate philosophical choice — valuing minimalism and the traditional Unix approach — rather than one offering clear practical advantages for typical homelab service hosting.
Final Thoughts
Understanding systemd vs OpenRC vs runit provides real context for the systemd criticism mentioned in the earlier dedicated guide, and practical relevance if you’re working with Alpine-based containers or considering a deliberately minimalist distribution like Void Linux. For the vast majority of homelab services covered throughout this series, systemd’s dominance and integrated tooling remain the practical default — but knowing what the alternatives actually look like helps make that choice an informed one rather than simply the unexamined default.
Leave a Reply