About Systemd

Every Linux system needs one process to start first — the one that gets everything else running, starts your services, and keeps track of what’s supposed to be alive at any given moment. On nearly every modern distribution, including Debian and Ubuntu, that process is systemd. This chapter is about what it actually does and why it looks the way it does, before touching any of its commands directly.

The Job Of PID 1

The very first process the kernel starts during boot is always assigned process ID 1. Nothing creates it — the kernel launches it directly, and every other process on the system is either a direct or indirect descendant of it. Whatever program holds PID 1 has one core responsibility: start everything else the system needs, and stay alive for as long as the system is running, since if PID 1 ever dies, the entire system typically goes down with it.

On Debian and Ubuntu, and most other current distributions, that program is systemd. Confirm it yourself:

ps -p 1

    PID TTY          TIME CMD
      1 ?        00:00:02 systemd

Before systemd: A Quick Word On Why It Exists

Older Linux systems used a much simpler approach, generally referred to as SysV init (after the System V Unix lineage it descended from). Startup was handled by a sequence of shell scripts, run one after another in a fixed numeric order, each responsible for starting one service. It worked, but it had real limitations: scripts ran strictly sequentially even when several services had no actual dependency on each other, so boot time added up linearly; there was no built-in way to express “start this service, but only after that other one is actually ready”; and a hung script could stall the entire boot process behind it.

systemd was built to address exactly these problems. Instead of ordered shell scripts, it uses declarative configuration files — you’ll get into their structure in a later chapter — describing what a service needs and depends on, letting systemd figure out the actual startup order and run independent services in parallel wherever possible, dramatically reducing boot time on a typical system.

More Than Just An Init System

systemd has grown well beyond “the thing that starts services.” On a typical Debian or Ubuntu system, it’s also responsible for:

• Logging — the same journal you’ll work with directly through journalctl later in this section
• Managing mount points — automatically mounting filesystems, in some ways overlapping with what you already do manually through /etc/fstab
• Device and hardware event handling — reacting to things like a USB drive being plugged in
• User sessions — tracking logged-in users and their processes

This broader scope is genuinely controversial in parts of the Linux community — some argue a single system component doing this much violates the traditional Unix philosophy of small, focused tools each doing one job well. That debate is worth being aware of if you encounter it, but it doesn’t change the practical reality: systemd is what you’ll be working with on the overwhelming majority of systems you’ll ever administer, controversy aside.

The Building Block: Units

Nearly everything systemd manages — a service, a mount point, a scheduled timer, a device — is represented as a unit, described by a configuration file. A service unit describes how to start, stop, and monitor one specific program. This is the concept the rest of this section builds on directly: once you understand that a “unit” is systemd’s standard way of representing something it manages, the commands for controlling those units — covered in the chapters ahead — stop feeling like arbitrary syntax and start feeling like a consistent, predictable system.

What’s Next

With the reasoning behind systemd’s design in place, the next chapter goes further into units specifically — the different types that exist, and how systemd uses targets to represent a coherent overall system state, replacing what older systems called “runlevels.”