An init system is the program that the Linux kernel starts as the first user-space process, PID 1, and that is responsible for bringing the rest of the operating system up, keeping services running and shutting everything down cleanly. Often simply called init, it sits at the boundary between kernel boot and normal operation, and every other process on the system descends from it.
In Linux system initialization, the init system turns a freshly booted kernel into a usable machine: it mounts file systems, configures devices and networking, starts daemons in the right order and provides login prompts or a graphical session. The dominant implementation today is systemd, while SysVinit, OpenRC, runit and s6 remain in use on specific distributions and in minimal environments.
Where the init system fits in the boot sequence
The init system takes over after the bootloader and kernel have done their work. Firmware loads a bootloader such as GRUB or systemd-boot, which loads the kernel and usually an initramfs, a small temporary root file system. Code in the initramfs finds and mounts the real root file system, then hands control to the init program on it.
The kernel looks for init at a fixed path, normally /sbin/init, which on most current distributions is a link to systemd. The path can be overridden with the init= parameter on the kernel command line, a technique administrators use for recovery, for example init=/bin/sh to get a root shell without starting services.
The following table outlines the boot stages and the component responsible for each.
| Stage | Component | Main task |
|---|---|---|
| Firmware | UEFI or BIOS | Initializes hardware and finds a bootloader |
| Bootloader | GRUB or systemd-boot | Loads kernel, initramfs and command line |
| Kernel | Linux kernel | Initializes drivers, memory and the scheduler |
| Early user space | initramfs | Unlocks and mounts the real root file system |
| Init system | PID 1 such as systemd | Starts services and reaches the target state |
| User session | Login manager or getty | Provides login and user processes |
Responsibilities of PID 1
PID 1 has special duties that no other process has. The kernel treats it as immortal: if PID 1 exits, the kernel panics. It is also the reaper of orphaned processes, because any process whose parent dies is re-parented to PID 1, which must collect its exit status with wait() to prevent zombie processes from accumulating.
- Service startup: launching daemons in dependency order, from file system checks to network services and web servers.
- Supervision: noticing when a service crashes and restarting it according to its policy.
- State management: moving the system between modes such as rescue, multi-user and graphical.
- Signal handling: reacting to Ctrl+Alt+Del, power button events and shutdown requests.
- Orderly shutdown: stopping services, syncing and unmounting file systems, then asking the kernel to power off or reboot.
PID 1 also receives different signal semantics: the kernel does not deliver signals to it unless it has installed a handler. This matters inside containers, where an application running as PID 1 may ignore SIGTERM and fail to stop cleanly unless a minimal init such as tini or a built-in init option is used.
Major init systems compared
Init systems differ in how services are described, ordered and supervised. Classic designs run shell scripts in a fixed sequence; modern designs read declarative definitions and compute a dependency graph.
| Init system | Service definition | Startup model | Typical home |
|---|---|---|---|
| SysVinit | Shell scripts in /etc/init.d | Sequential by numbered links per runlevel | Older distributions and legacy systems |
| systemd | Declarative unit files | Parallel, dependency and socket based | Most major distributions |
| OpenRC | Shell-based scripts with dependency headers | Dependency based, optional parallelism | Gentoo and Alpine Linux |
| runit | Small run scripts per service | Supervision trees, fast startup | Void Linux and containers |
| s6 | Service directories | Strict supervision with readiness notification | Minimal and embedded systems |
The concept of a runlevel, numbered states from 0 to 6 in SysVinit, has been replaced in systemd by targets such as multi-user.target and graphical.target. systemd still provides compatibility aliases, so runlevel3.target maps to the multi-user state.
Design approaches and their trade-offs
The central design debate concerns scope. Minimalist init systems do one job, start and supervise processes, and leave logging, device management and scheduling to separate tools. systemd integrates many of these functions, including the journal, timers, login sessions and network configuration, into one coordinated suite.
| Property | Script-based init | Integrated init such as systemd | Supervision-focused init |
|---|---|---|---|
| Boot speed | Slower, mostly sequential | Fast, parallel and on demand | Fast, small overhead |
| Dependency handling | Manual ordering | Automatic from unit relations | Explicit per service |
| Crash recovery | Usually none built in | Restart policies per unit | Core design goal |
| Resource control | External tools | Built-in cgroup management | Optional add-ons |
| Code size and complexity | Small core, complex scripts | Large suite | Very small |
Techniques such as socket activation, where the init system opens a listening socket and starts the service only on the first connection, allow parallel startup without strict ordering. They also reduce memory use for rarely used services.
Troubleshooting boot and service problems
Most init-related failures show up as a boot that stops or a service that fails to start. The first step is to read logs from the current and previous boot, for example with journalctl -b and journalctl -b -1 on systemd systems, or the files under /var/log on others.
- Emergency or rescue mode usually points to a failed mount, often a wrong entry in /etc/fstab or a missing disk.
- Dependency loops between services cause the init system to skip or delay units; the logs name the cycle.
- Slow boots can be analyzed with
systemd-analyze blameandsystemd-analyze critical-chain. - Services that restart repeatedly need a look at their exit codes and restart limits, not just at the restart policy.
- Recovery without services is possible by adding
systemd.unit=rescue.targetorinit=/bin/shto the kernel command line.
A common mistake is editing distribution-provided unit files or init scripts directly. Package updates may overwrite them; overrides in /etc, such as drop-in files created with systemctl edit, survive updates and keep local changes visible.
Stripped to the essentials
An init system is like the stage manager of a theater. When the doors open, the stage manager turns on the lights, checks the sound and calls each performer at the right moment. If an actor misses a cue, the stage manager notices and sends them back on.
At the end of the show, the stage manager closes everything in the correct order. On a Linux computer, the init system plays that role from power-on to shutdown.
Where it is applied
An administrator manages a web server that sometimes fails to come back after maintenance reboots. The web application starts before the network storage is mounted, the storage that holds its files, crashes, and stays down until someone restarts it by hand.
Instead of adding a fixed delay to a startup script, the administrator uses the init system’s dependency model. A drop-in override declares that the web service requires the storage mount and starts after it, and sets a restart policy with a short delay and a sensible limit.
After the next reboot, the init system mounts the storage first, then starts the application, and restarts it automatically if it ever crashes. The boot order is now documented in configuration rather than in someone’s memory, and maintenance reboots no longer need manual follow-up.