Linux concept: systemd

1. The Basics

The job of systemd is to be the system and service manager for Linux. When your machine boots, the kernel starts exactly one program directly, and gives it process ID 1 (PID 1). On nearly every mainstream distribution that program is systemd. Everything else you can see running, from a web server to a background timer to the mounting of a disk, is a child that systemd started, tracks, and can stop again.

Because it is PID 1, systemd is special. It is the ancestor of every other process, it never exits while the system runs, and if it were to crash the kernel would panic. So systemd has to be careful, small in its core, and reliable. It does its job by reading a set of description files called units and acting on them.

The key idea is the unit. Systemd does not think in terms of "programs" or "scripts". It thinks in units: small declarative files that describe something it should manage and how. The most common kind is the service, but there are units for mount points, timers, sockets, network devices, and whole system states. Every unit has a name ending in a type suffix, such as ssh.service or graphical.target.

The right mental model: systemd is the one manager that runs the entire machine, from the first second of boot to shutdown, and every manageable thing on the system, a service, a mount, a timer, a target, is described to it as a unit.

You do not usually talk to systemd directly. You use its family of command-line tools, above all systemctl to control units and journalctl to read logs. This article is about the manager itself: what it is, how it boots your machine, how units and targets fit together, how it tracks processes with control groups, and the surprising amount of a modern Linux system that is really systemd wearing different hats. It is verified against systemd version 255.

1.1 Seeing That systemd Is PID 1

You can confirm systemd is in charge with one command. Process 1 is the manager, and the boot program /sbin/init is just a link to it:

$ ps -p 1 -o comm=
systemd

$ ls -l /sbin/init
/sbin/init → /lib/systemd/systemd

For decades /sbin/init was the real first program. Today it points at systemd, which keeps old habits and boot loaders working while systemd does the actual job.

1.2 The First Look: What Is Running

To see what systemd is managing right now, ask it to list its units. Reading state needs no special rights:

$ systemctl                       # every unit currently loaded
$ systemctl status                # a tree of the whole system
$ systemctl list-units --type=service --state=running

The output shows each unit, whether systemd loaded it correctly, and whether it is active. That single view, everything on the machine in one list, is the practical payoff of having one manager instead of a pile of separate scripts.

1.3 The Main Unit Types

Because "unit" is the one idea that ties systemd together, it helps to see the common types at a glance. The suffix on a unit's name tells you what kind it is, and the same verbs (start, stop, enable, status) work on all of them:

Most days you touch only .service and .target units, but the rest use the exact same tools, which is a large part of systemd's appeal.

3. A Short History

To understand systemd you have to know what it replaced, because it changed how Linux starts up more than any other single project in the last twenty years.

For most of Unix history, the first program the kernel started was init, and the traditional design was SysV init, named after AT&T's UNIX System V. It was a set of shell scripts under /etc/init.d, run in a fixed order by numbered "runlevels". It worked, but it was slow, because it started services strictly one after another, and fragile, because each service was a hand-written script that had to track its own process. Booting a big server could take minutes.

Attempts to modernise init came first. Ubuntu shipped Upstart in 2006, an event-based system that reacted to things happening rather than a fixed script order. It was a real improvement, but it kept the script-heavy style.

systemd, first released in 2010 by Lennart Poettering and Kay Sievers at Red Hat, set out to replace init entirely with a new design. Its big ideas were:

• Describe services as small declarative unit files instead of shell scripts, so the manager, not each script, does the heavy lifting.
• Start independent services in parallel, using dependencies to work out the order, for a much faster boot.
• Track every service's processes reliably with kernel control groups (cgroups), so a service and all its children can always be found and stopped.
• Collect all logs into one structured journal instead of scattered text files.

The move was not without argument. systemd is large and does much more than the old init, taking on jobs such as logging, network setup, and device management that used to belong to separate programs. Some administrators dislike this reach, and a few distributions (such as Devuan, a systemd-free fork of Debian) deliberately avoid it. But on a default modern install, systemd is what boots and runs your machine, and learning it is no longer optional.

5. Moderate Use Cases

Once the basics feel routine, the next step is to describe your own work to systemd. This is where units stop being something the distribution ships and start being something you write.

5.1 Anatomy of a Unit File

A unit file is a plain text file in "INI" style: named sections in square brackets, each holding Key=Value lines. A service unit uses three sections, and each has a clear job:

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/opt/myapp/app.sh
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

You save this as /etc/systemd/system/myapp.service, tell systemd to re-read its files, then enable it:

$ sudo systemctl daemon-reload       # systemd notices the new file
$ sudo systemctl enable --now myapp   # start it now and at every boot

The Restart=on-failure line is one of the strongest reasons to prefer a real unit over a hand-run script: if your program crashes, systemd brings it back automatically.

5.2 Targets: Grouping Units into System States

A target is a special unit that does not run a program. Instead it groups other units and stands for a whole system state. Targets are systemd's replacement for the old numbered runlevels:

The system boots into whatever default.target points to. You can read it, change it, or switch the running machine into another state:

$ systemctl get-default                         # e.g. graphical.target
$ sudo systemctl set-default multi-user.target  # boot without a desktop
$ sudo systemctl isolate rescue.target          # switch to rescue mode now

5.3 Timers: A Modern Replacement for cron

For decades, scheduled jobs meant cron. systemd offers its own scheduler in the form of timer units. A timer is a small unit that says when, paired with a service that says what. The pair looks like this:

# backup.timer
[Unit]
Description=Nightly backup

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

The matching backup.service holds the ExecStart= that does the work. Timers have real advantages over cron: they log to the journal like any service, they can catch up a missed run with Persistent=true, and you can list them all with one command:

$ systemctl list-timers            # every timer, next and last run time

7. Something Most Users Do Not Know

7.1 systemd Is Not One Program, It Is a Whole Fleet

People say "systemd" as if it were a single binary, but it is a large collection of programs that work together. The manager at PID 1 is only the core; around it sit dozens of specialised daemons and tools. A quick look under /lib/systemd/ shows the scale:

$ ls /lib/systemd/systemd-*
systemd-journald   systemd-logind    systemd-udevd
systemd-networkd   systemd-resolved  systemd-timesyncd
systemd-oomd       systemd-homed     ... (dozens more)

Each takes on a job that used to belong to a separate, independent project:

This is exactly what its critics mean by "systemd does too much" and its fans mean by "it is finally consistent". Either way, it explains why the project feels so big: it is not one tool, it is a coordinated suite that took over many jobs at once.

7.2 Where systemd Sits in the Whole Boot

systemd does not start the machine from nothing; it takes over partway through a longer chain. Knowing the full sequence tells you which part is systemd's job and which happens before it even loads:

1. Firmware (UEFI or BIOS)   powers up and finds a boot device
2. Bootloader (GRUB)         loads the kernel and initramfs
3. Linux kernel              starts and detects hardware
4. initramfs                 tiny temporary root, mounts the real disk
5. systemd (PID 1)           takes over as the first real process
6. Targets reached           services started up to the default target
7. Login prompt or desktop   the system is ready

Everything up to step 4 happens before systemd exists, so a failure there, such as a missing kernel or a broken bootloader, is not something systemd can report. From step 5 on, the machine is systemd's responsibility, and it works upward through a chain of targets, each one a milestone:

local-fs.target      →  filesystems mounted
       ↓
sysinit.target       →  early one-time setup done
       ↓
basic.target         →  sockets, timers, and paths ready
       ↓
multi-user.target    →  all normal services running
       ↓
graphical.target     →  desktop login on top

Each target says it must come After= the previous one and Wants= the services in its group. Systemd starts everything it safely can in parallel within each stage, which is why a systemd boot is so much faster than the strict one-at-a-time order of SysV init. You can see the exact chain that gated your own boot with systemd-analyze critical-chain.

7.3 "Enabling" a Service Is Just a Symbolic Link

The word enable sounds like it flips a hidden switch. It does something far simpler: it creates a symbolic link. A unit's [Install] section names the target that wants it, such as WantedBy=multi-user.target. Enabling the unit makes a symlink to it inside that target's .wants directory:

$ sudo systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service
               → /lib/systemd/system/nginx.service.

At boot, systemd reaches multi-user.target, sees the symlinks in its .wants directory, and starts each linked unit. That is the entire mechanism. Disabling just deletes the link, and masking a service links its name to /dev/null so nothing can start it. Once you know this, enabling stops being magic and becomes files you can list with ls.

7.4 systemd Talks to You Over D-Bus

When you run systemctl restart nginx, the systemctl program does not touch nginx at all. It sends a message to systemd (PID 1) over D-Bus, the standard message bus Linux programs use to talk to each other. systemd receives the request, checks whether you are allowed to make it, does the work, and records the result. This design explains several things:

• A polkit password dialog can appear on a desktop, because D-Bus lets systemd ask an authorization service whether to permit the action.
• Any program can manage services by speaking the same bus, not only systemctl; you can watch that traffic with busctl.
• systemctl is a thin client. The intelligence lives in the manager it talks to, not in the command.

7.5 It Tracks Processes by cgroup, So Nothing Escapes

Old init systems tracked a service by its PID file, and a program that forked cleverly could slip loose and keep running as an orphan. systemd closes that gap: because every service lives in its own cgroup, a stray child stays inside the same group no matter how it forks. When systemd stops the service, it stops the whole cgroup, so there are no leftover processes. This is why a modern systemctl stop is so much more reliable than the old "kill the PID and hope" approach, and it is the same accounting that lets systemd report a service's exact memory use.

7.6 You Can Boot Straight Into a Shell

Because targets are just system states, you can ask systemd for a minimal one at boot time by editing the kernel command line. Adding systemd.unit=rescue.target boots to a single-user rescue shell; emergency.target gives you the barest shell of all, useful when a broken /etc/fstab stops a normal boot. This is the systemd equivalent of the old trick of appending single or a runlevel number, and it turns "the machine will not boot" into a problem you can often fix from the same console.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Forgetting daemon-reload after editing a unit. This is the number-one cause of "my change did nothing". systemd is still using the cached copy.
• Editing files in /lib/systemd/system. The next package update silently overwrites them. Keep your changes in /etc/systemd/system or a drop-in.
• Looking for a user service in the system view. A unit started with --user will not show under a plain systemctl status. Add --user to see it.
• Confusing the unit name with the process name. The unit may be ssh.service while the running program is sshd. Use tab completion or systemctl list-units to find the exact unit.
• Assuming logs live in /var/log/*.log. On a default systemd system the record is the journal; read it with journalctl, not by opening text files.
• Ordering without requiring, or the reverse. After= sets order but not dependency; Requires= sets dependency but not order. Real dependencies usually need both.