Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Linux Init Systems — Field Guide

Overview

Every Linux system runs exactly one first userspace process — PID 1 — and whatever that process is defines the shape of the whole machine: how services start and stop, whether a crashed daemon comes back, how logs are captured, how resources are accounted, how you boot into rescue mode, and even what “the system is in state X” means. The init system is the least optional piece of software on a Linux box: everything else can be replaced or removed, PID 1 cannot.

This section is a complete, implementation-level tour of the five init systems that matter in practice: systemd (the default almost everywhere), sysvinit (the traditional System V scheme that ran Linux for two decades and still runs Devuan, Slackware and antiX), OpenRC (dependency-aware shell scripts — Gentoo, Alpine, Artix), runit (supervision-first, minimal — Void Linux), and dinit (a modern dependency graph with supervision — Chimera Linux, eweOS, an Artix option).

Each family gets its own sub-section of deep pages covering inner workings, usage, configuration, tooling, APIs, and operational patterns, with links to upstream source, wikis, man pages, and API references. A single comparison page lines all five up feature-by-feature and gives porting maps between their commands.

What an init system actually does

Whatever the implementation, PID 1 has a small set of unavoidable jobs, and each init system answers them differently:

  1. Boot the system — mount filesystems, fsck, bring up device handling, and start the services that make the machine usable (network, logging, login prompts).
  2. Supervise services — start them, track their processes, restart them when configured to, and stop them cleanly on shutdown. How much of this is real supervision vs “run a shell script and hope” is the biggest dividing line between the five systems.
  3. Express dependencies and ordering — “start sshd only after the network is up” must be declarable somewhere, from sysvinit’s static sequence numbers through LSB headers to systemd’s and dinit’s runtime dependency graphs.
  4. Manage system state — runlevels (sysvinit, OpenRC), targets (systemd), or stages (runit): the named states a system moves between.
  5. Handle shutdown, rescue and reboot — run stop scripts in reverse order, get you a sulogin prompt when boot fails, and turn the power off.

From these jobs, everything interview-relevant follows: why systemd can boot in parallel while sysvinit mostly cannot, why KillMode= exists, why runit has no dependency engine, and why OpenRC is not PID 1 on most systems that run it.

Distro defaults at a glance

DistributionDefault initAlso available
Fedora, RHEL, SUSE, Arch, Debian, Ubuntusystemd— (Debian: others via remixing)
DevuansysvinitOpenRC, runit
Slackware, antiX, PCLinuxOSsysvinit—
GentooOpenRCsystemd
Alpine LinuxOpenRCrunit, (s6-based image)
Artix Linuxchoice at installOpenRC, runit, dinit, s6
Void Linuxrunit—
Chimera Linux, eweOSdinit—
Most embedded firmwarebusybox init or nonesysvinit-style scripts

The pattern worth noticing: everything mainstream converged on systemd, and the remaining diversity lives deliberately in distributions and embedded projects that made init choice a design goal. That split is itself an interview topic — see the migration and landscape page.

Section map and reading order

If you are new, read the first two bullets of each row; the rest is reference depth. Every page is self-contained and cross-linked.

systemd — 16 pages

sysvinit — 16 pages

OpenRC — 4 pages

runit — 4 pages

dinit — 4 pages

Cross-cutting

  • Comparison — feature matrix, command porting map, decision guide

How to choose what to study

For placement interviews, systemd and sysvinit dominate the question space — systemd because it is what you will actually operate, sysvinit because its concepts (runlevels, init scripts, rc ordering) remain the vocabulary of every “describe the Linux boot process” question, and the contrast explains why systemd is designed the way it is. OpenRC, runit and dinit questions appear in infra-heavy and embedded shops, and knowing one alternative init well is a strong differentiator because most candidates know only systemd.

A practical path: the two boot-process pages, both runlevel pages, one service-management page per family, then the comparison. From there, follow the cross-references from whatever your current role touches most — logging (journald), scheduling (timers), or devices (udevd).

Interview Questions

Q: What does an init system do, and what is the deepest architectural difference between systemd and sysvinit?

It is PID 1: it bootstraps userspace, starts and supervises services, resolves startup dependencies, manages system states, and handles shutdown. The deepest difference is the supervision model: sysvinit executes shell scripts once per runlevel and has no daemon after that — a service that dies stays dead until something reruns the script — while systemd keeps every service in its own cgroup, tracks its main process, and applies Restart= policies continuously. Almost every other difference (parallel boot, socket activation, journal, resource control) follows from systemd turning service management into a resident, stateful engine rather than a boot-time script runner.

Q: Why is OpenRC usually not PID 1 even on systems that “use OpenRC”?

Because OpenRC is a runlevel and dependency engine, not a process supervisor by default. Classically, sysvinit stays PID 1 and its inittab invokes openrc sysinit, openrc boot, and openrc default at the right points; OpenRC then computes the dependency order and runs the service scripts. openrc-init exists as an optional PID 1 replacement, but most deployments keep the classic split. This is a common interview trap: “Gentoo’s init system” is really a two-piece arrangement.

Q: Which init would you pick for a container, and why is the answer often “none”?

Containers usually run one application, so a full init buys little; the real question is zombie reaping and signal forwarding, since PID 1 in a container inherits those duties. A tiny supervisor like tini or dumb-init — or runit’s runsvdir for multi-process images — covers that without systemd’s footprint. If you genuinely need multiple supervised services, runit or OpenRC inside the container are established patterns, while systemd in containers is possible but heavy. See the migration page’s container section.

Q: What is one capability each init system has that the others lack?

sysvinit: none of them beats its auditability — every service start is a shell script you can read with no daemon magic. systemd: socket activation and cgroup-scoped kill/restart, which no other init in this section matches in maturity. OpenRC: dependency-aware scripts — you keep plain shell services but get a real dependency solver. runit: rock-solid minimal supervision with per-service logging out of the box. dinit: a systemd-like dependency graph (with proper failure semantics) in a tiny, dependency-light binary.

Key Takeaways

  • PID 1 defines the machine: supervision, dependency resolution, state management, shutdown — every other behavior follows from how the init system answers those four jobs.
  • systemd won by turning init into a resident transactional engine; sysvinit remains the conceptual baseline (runlevels, rc scripts) everyone is tested on; OpenRC, runit and dinit are the maintained alternatives, each with a different core bet (scripts+deps, supervision, graph+supervision).
  • The comparison page’s porting map is the fastest way to translate habits between systems; each family’s pages link upstream source, wikis, man pages and API docs for ground truth.

Cross-References

References