systemd vs. OpenRC vs. runit: Comparing Init Systems for Servers and Containers

1. What PID 1 actually does

Once the kernel finishes its own initialization, it starts exactly one userspace process with process ID 1, which from that moment on forms the root of the entire process tree. That process is handed a special responsibility: it has to reap orphaned child processes, avoid so called zombie processes, start system services in the correct order, and ideally also watch whether a service exits unexpectedly.

Historically, SysVinit filled this role on most Unix like systems, running sequentially executed shell scripts inside numbered runlevel directories. Modern init systems like systemd, OpenRC, and runit differ mainly in how much of that responsibility actually lives inside PID 1 itself, and how much service supervision, logging, and dependency handling are implemented as distinct, well defined building blocks rather than a loose collection of shell scripts.

2. systemd architecture: units and parallel startup

systemd describes services, mount points, devices, timers, and sockets uniformly as units in declarative configuration files, rather than as executable scripts. A service unit file defines its dependencies on other units through directives like After, Requires, and Wants, from which systemd builds a full dependency graph at boot and starts services without a hard dependency on each other in parallel rather than sequentially.

This parallel startup strategy noticeably shortens boot time compared to a strictly sequential SysVinit approach, but it also brings a considerably larger attack surface and code base, since systemd bundles logging through journald, network configuration through systemd-networkd, device management through udev, and numerous other components alongside pure process management in the same project.

# Inspect the dependencies of a service unit
systemctl show -p After -p Requires -p Wants nginx.service

# Print the full dependency graph as a text tree
systemd-analyze critical-chain nginx.service

# Boot time breakdown per unit
systemd-analyze blame

3. OpenRC architecture: shell scripts with a dependency system

OpenRC still relies on classic shell scripts for individual services, but adds its own dependency system, described through the need, use, and after directives in each script, which enables correct ordering and partial parallelism at startup without fully giving up the simplicity of plain shell scripts.

Since OpenRC is not a big bang redesign the way systemd is, but deliberately builds on a lean, POSIX close foundation, resource usage of PID 1 itself stays minimal, while actual process supervision runs optionally through the separate s6 tool or OpenRC's own supervise-daemon command, rather than being hardwired into PID 1.

# OpenRC service script, trimmed example (/etc/init.d/myapp)
#!/sbin/openrc-run
name="myapp"
command="/usr/bin/myapp"
command_args="--config /etc/myapp/config.yml"
command_background=true
pidfile="/run/myapp.pid"

depend() {
    need net
    after firewall
}

# Enable the service and check its status
rc-update add myapp default
rc-service myapp status

4. runit architecture: supervision trees as the core principle

runit takes a radically minimalist approach modeled on daemontools: every supervised service gets its own directory with a simple run script that starts the service in the foreground, while the supervisor process runsv keeps running alongside it and immediately restarts the service on an unexpected crash, without needing a complex configuration language.

This structure, known as supervision trees, makes runit especially predictable: there is practically no hidden global state, every service can be controlled in isolation with sv start, sv stop, or sv status, and the entire init system consists of only a few thousand lines of C code, which makes audits and a full understanding of its behavior considerably easier.

# runit service directory, minimal example
mkdir -p /etc/sv/myapp
cat <<'EOF' > /etc/sv/myapp/run
#!/bin/sh
exec 2>&1
exec /usr/bin/myapp --config /etc/myapp/config.yml
EOF
chmod +x /etc/sv/myapp/run
ln -s /etc/sv/myapp /var/service/myapp

# Query service status and restart it
sv status myapp
sv restart myapp

5. Service supervision compared directly

With systemd, supervision is built directly into PID 1: Restart directives in the unit file let systemd itself decide whether and how often a crashed service gets restarted automatically, including a configurable backoff strategy through StartLimitIntervalSec and StartLimitBurst, without needing an extra process for it.

runit achieves the same goal through a dedicated runsv process per service, structurally independent from PID 1 itself, while OpenRC delegates actual supervision optionally to supervise-daemon and, without that explicit configuration, does not automatically restart a crashed service, but merely reports it as stopped the next time it is checked manually or on a schedule.

6. Why systemd became the standard on servers

systemd established itself as the standard mainly because it goes far beyond pure process management, delivering a coherent ecosystem with journald, systemd-networkd, systemd-resolved, systemd timers, and cgroup based resource control that covers many tasks classic init systems needed separate, loosely coupled tools for, such as cron, syslog, or NetworkManager.

For ops teams, that means a unified command line through systemctl and journalctl for practically every system aspect, solid documentation, broad distribution support from Debian through RHEL to SUSE, and a huge ecosystem of ready made unit files, which significantly reduces practical effort compared to the theoretically leaner but more fragmented toolbox of OpenRC or runit.

7. When Alpine and Void choose lean container images

Alpine Linux deliberately relies on OpenRC instead of systemd, because musl libc and BusyBox as its foundation are already optimized for minimal size, and a full blown systemd with its cgroup, DBus, and journal underpinnings would fundamentally work against that goal. For container base images, where every extra megabyte of image size and every extra bit of attack surface matters, OpenRC's lean footprint fits noticeably better.

Void Linux goes a step further toward minimalism and predictability by using runit as its default init system, while in practice many containers do not need a full init system at all: a single process per container with a lean signal handler like tini is already enough for most containerized applications, so the init system debate in container environments often ends up limited to side processes such as cron jobs running inside a container.

# Alpine container: set up an OpenRC service inside a Docker image
FROM alpine:3.20
RUN apk add --no-cache openrc myapp
RUN rc-update add myapp default
CMD ["/sbin/openrc-run"]

# Alternative: a minimal signal handler instead of a full init system
CMD ["tini", "--", "/usr/bin/myapp"]

8. Practical consequences for day to day ops

Logging differs noticeably: systemd collects structured logs in binary form through journald, with journalctl as the query tool, while OpenRC and runit rely on classic text files or external loggers like syslog-ng, which are less conveniently searchable but avoid additional journal rotation and binary format dependencies, and feed more easily into existing log aggregation pipelines.

Debugging commands differ accordingly: under systemd, systemctl status immediately shows exit code, the latest log lines, and dependency status in a single output, while under OpenRC rc-service status and under runit sv status each only show plain runtime status, requiring a separate look at the relevant log file for details.

9. Recommendation by use case

For classic virtual or physical servers with mixed services, network configuration, and complex dependencies, systemd remains the pragmatic default choice, if only because of broad distribution support and a huge ecosystem of ready made unit files for practically any common server software.

For lean container base images, minimalist embedded systems, or environments where predictability and a small audit surface matter more than a rich feature set, OpenRC and runit offer a deliberate, well reasoned alternative that has worked reliably for years in its respective niche and should by no means be considered outdated there.

10. Summary

11. FAQ: Init Systems