init and systemd

As The Boot Process and GRUB showed, once the kernel has started and mounted the real root filesystem, it hands control to the first user-space process — the one with process ID 1. That single process is responsible for starting everything else the system needs: services, networking, the login prompt, all of it. The identity and behavior of that process changed fundamentally once in Linux history — the move from the old init model to today's systemd. Understanding that shift, and why systemd became the default on nearly every modern distribution, explains why the unit, target, and service-management mechanisms covered in the following articles are built the way they are.

What You Will Learn

By the end of this article you will be able to:

• explain what PID 1 is responsible for and why it deserves special care;
• describe how SysV init and its runlevel model worked;
• list the main reasons systemd replaced SysV init as the default;
• recognize the overall shape of the systemctl command and how it relates to other systemd tools;
• check which init system a given machine is actually running.

PID 1: the System's Root Process

Every Linux process is created (forked) by another process — except exactly one: PID 1. It is started directly by the kernel, as the final step of the boot sequence.

ps -p 1 -o pid,comm

    PID COMMAND
      1 systemd

PID 1 has two distinct responsibilities:

• starting the system — bringing up services, mount points, and other resources in the right order;
• reaping — cleaning up "orphaned" processes whose parent has already exited but that have not yet been fully removed from the system.

If PID 1 itself crashes, the kernel takes the whole system down with a kernel panic — which is exactly why this process is written far more carefully than an ordinary program.

SysV init and the Runlevel Model

Before systemd became widespread — and still, on some older or specialized systems today — PID 1's job was handled by SysV init. Its model was built around runlevels: numbered states from 0 to 6 describing what the system was doing.

Transitions between runlevels and the default runlevel were configured in /etc/inittab, and services were started or stopped by scripts under /etc/init.d/, one after another, in sequence. This model had a few structural weaknesses:

• because services started sequentially, boot time grew roughly linearly with the number of services;
• dependencies between services were expressed informally, through naming conventions in scripts (S20network), which was rigid and error-prone;
• there was no standard way to check whether a started service was actually ready or working, only that its start script had run.

Why systemd Became the Default

systemd is a modern init and service manager, originally developed by Red Hat engineer Lennart Poettering, built to take on PID 1's role. It addresses SysV init's limitations directly:

• parallel startup — services with no dependency on each other start at the same time, cutting boot time significantly;
• declarative dependencies — each service declares its relationship to other units (After=, Requires=, Wants=) in its own .service file, and systemd computes the correct order from that dependency graph itself;
• socket and D-Bus activation — a service can start on demand, only when its first request arrives, saving resources;
• one consistent tool family — managing services (systemctl), reading logs (journalctl), and configuring time and locale (timedatectl, localectl) are all handled through the same coherent command family;
• isolation through cgroups — each service runs in its own control group, which makes resource accounting and complete process cleanup far more reliable.

The runlevel concept itself is replaced in systemd by targets — covered in detail in systemd Units and Targets.

Checking Which Init System Is Running

ps -p 1 -o comm=

systemd

Or check the systemd version directly:

systemctl --version

systemd 255 (255.4-1ubuntu8)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP ...

If the result is not systemd — say, init or something else — the system is running SysV init or another alternative, and the systemctl/journalctl commands in the following articles will not apply directly.

A Quick Look at the systemd Command Family

systemd ships with several distinct commands, each responsible for its own area:

This article only introduces the essentials of systemctl — the full picture is covered in systemd Units and Targets and Service Management.

systemctl status

● ubuntu-server
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Fri 2026-07-24 08:12:03 UTC; 3h 40min ago

Run without arguments, systemctl status shows the overall state of the system: how many units have failed, when the system booted, and its current state (running, degraded, and so on).

Common Mistakes

Using SysV init Commands on a systemd System

Old commands like service nginx restart or /etc/init.d/nginx restart still work on most systemd systems for compatibility (systemd translates them internally into a systemctl call), but this is a temporary compatibility layer — richer error messages and extended features (such as --now, or displaying dependencies) are only fully available through systemctl directly.

Treating PID 1 as an Ordinary Process

Trying to stop PID 1 with kill -9 1, or otherwise managing it like a regular process, can leave the system unstable or trigger a kernel panic. Any interaction with PID 1 should go through systemd's own official tools (systemctl reboot, systemctl poweroff).

Confusing "systemd" with "systemctl"

systemd is the daemon running as PID 1; systemctl is the client command used to talk to that daemon. Stopping systemctl does not stop systemd — it is only a management tool.

Exercises

1. Run ps -p 1 -o pid,comm and systemctl --version and explain the output of each.
2. Explain, in your own words, what the State, Jobs, and Failed fields in systemctl status output mean.
3. Recall which systemd target corresponds to SysV init runlevel 3 (you'll confirm the answer in systemd Units and Targets).
4. Open man systemd and count how many systemd components (such as systemd-journald, systemd-logind) are listed under "See Also".

Verification criterion: you should be able to state, without looking it up, what PID 1 does and why killing it directly is dangerous.

Summary

PID 1 is the first user-space process, started by the kernel, responsible for everything else the system runs. Under SysV init, this job belonged to a sequential, runlevel-based init; systemd replaced it with parallel startup, declarative dependencies, and a single consistent command family, cutting boot time and simplifying management. The next article, systemd Units and Targets, covers systemd's core building block — the unit — and the target mechanism that replaced runlevels, in detail.

References

• freedesktop.org: systemd(1)
• man7.org: init(1)
• freedesktop.org: systemd — System and Service Manager
• Red Hat: Introduction to systemd