An init system is the program that turns a freshly booted kernel into a running, usable computer. When a Unix-like kernel finishes its own startup, it hands control to a single userspace program, which is given process ID 1. Everything else, every login session, every network daemon, every application, descends from that one process. The systemd manual page captures the role in describing what happens “when run as first process on boot (as PID 1)”: that process “acts as init system that brings up and maintains userspace services.” Init both starts the system and keeps it running.
PID 1 carries two distinctive responsibilities. First, it is the bootstrap: it mounts filesystems, starts the services the machine is supposed to offer, and brings the system to a defined operating state. Second, it is the ultimate parent and reaper. When any process loses its parent and is orphaned, it is reparented to PID 1, which is responsible for cleaning up after it. Because of this, init is never allowed to exit while the system is up; if PID 1 dies, the kernel panics.
The classic Unix answer was SysV init, which organized the system into numbered runlevels. The runlevel(8) manual page calls runlevels “an obsolete way to start and stop groups of services used in SysV init,” each runlevel corresponding to a state such as single-user, multi-user, or graphical. init read a configuration file and ran a sequence of shell scripts to enter the chosen runlevel. The model was simple and transparent, but the scripts ran largely in series, which made boots slow, and expressing dependencies between services was awkward.
The 2000s and 2010s brought a wave of replacements aimed at faster, dependency-aware, event-driven startup. Ubuntu’s Upstart and Apple’s launchd reworked the model around events and on-demand activation. systemd went furthest, replacing runlevels with target units and supervising services through declarative unit files; the runlevel(8) page now exists mainly to map the old numbers onto systemd targets, noting that “systemd can activate multiple targets concurrently, so the mapping to runlevels is confusing and only approximate.”
The deeper idea, though, is constant across all of these: somewhere there is a first process that must come up reliably, start everything else in the right order, and stay alive to look after the system for as long as it runs. The init system is where the abstract notion of “the computer is on and working” is actually implemented.
Because PID 1 sits at the root of the process tree, choices made by the init system ripple through everything above it. How services are described, how logs are collected, how the machine shuts down, and how a crashed daemon is restarted are all decided here, which is why changes to the init system, such as the broad move to systemd on Linux, are felt across the entire operating system.