Table of Contents
Overview: Where systemd Fits in Linux
systemd is the init system and service manager used by most modern Linux distributions. Its two main jobs are:
- PID 1 / init: it’s the first process that starts after the kernel and the ancestor of almost all other processes.
- Service and system manager: it starts, stops, and supervises services and other system resources.
Historically, Linux systems used SysV init or other init systems; systemd replaces most of that stack with a single, integrated framework.
Key points about systemd:
- It’s not just one program; it’s a suite of tools and daemons.
- It’s designed to be parallel, fast, and dependency-aware.
- It tries to provide consistent interfaces across distributions.
You’ll use systemctl and journalctl in later sections; here we focus on what systemd is conceptually and what components it includes.
Core Goals and Design Philosophy
systemd was created to solve limitations of older init systems. Some of its main goals:
- Fast boot and shutdown
- Start services in parallel when their dependencies allow.
- Delay starting some services until they are actually needed (on-demand activation).
- Explicit dependencies
- Services declare what they need (e.g., “start after the network is up”).
- systemd uses this to order startup and resolve what can run in parallel.
- Unified management
- Same tools and concepts work for:
- System services (daemons)
- Mount points
- Network services sockets
- Timers (cron-like jobs)
- Devices, swap, and more
- Better logging and debugging
- Tight integration with the system journal for structured logs.
- Track processes, restarts, and resource usage more easily.
- Cgroup-based management
- Uses Linux control groups (cgroups) to group and manage processes per service.
- Makes it easier to see which processes belong to which service and to limit resources.
systemd as PID 1: Replacing Traditional init
On a system using systemd, if you run:
ps -p 1 -o pid,cmdyou’ll typically see:
PID CMD
1 /sbin/init
On systemd systems, /sbin/init is usually a symlink to systemd. As PID 1, systemd:
- Starts the rest of the system:
- Mounts file systems (through units, not manual scripts).
- Starts essential services (logging, networking, etc.).
- Reaps orphaned and zombie processes.
- Controls shutdown and reboot ordering.
Unlike SysV init scripts (shell scripts in /etc/init.d), systemd uses declarative unit files that describe what should happen, not how to do it step by step.
The systemd Ecosystem: More Than One Binary
“systemd” often refers both to the init daemon and to the entire ecosystem of related components. Some important parts (names only for now; they each have their own deeper topics later):
systemd(PID 1): the main init/service manager.systemctl: command-line tool to interact with systemd (start, stop, enable services, etc.).journald/journalctl: logging daemon and its query tool.logind: manages user logins, sessions, seats.systemd-udevd: device event handling (often just calledudev).systemd-resolved: DNS/stub resolver service (optional, distro-dependent).systemd-networkd: network management daemon (used on some distros).systemd-timedated,systemd-timesyncd: time settings and basic NTP sync.
Distributions choose which of these they actually use by default, but the core service management behavior is shared.
Units: The Building Blocks of systemd
systemd doesn’t just manage “services”. It manages many kinds of system resources, each represented by a unit.
A unit is a configuration object that systemd understands and manages. Every unit has:
- A type (e.g., service, mount, timer).
- A name (e.g.,
sshd.service). - A unit file (e.g.,
/usr/lib/systemd/system/sshd.service).
You’ll learn how to manage units later; here we just focus on what they are conceptually.
Common unit types:
.service– background daemons (e.g.,sshd.service,cron.service)..socket– network or IPC sockets that can activate services on demand..target– logical groupings of units (similar to “runlevels”), likemulti-user.target,graphical.target..mount– file system mounts (e.g.,home.mount)..automount– on-demand mounts that trigger when accessed..timer– time-based triggers (cron-like functionality)..path– file or directory watchers that can start services when something changes..swap– swap space..slice,.scope– resource control and transient units (often created automatically by systemd).
systemd uses these units to model almost everything about the running system, which allows consistent control and dependency management.
Dependency-Driven and Parallel Startup
A key difference from traditional init systems: systemd is dependency-driven.
Each unit can specify:
- What it requires:
Requires=,Wants= - Ordering constraints:
Before=,After= - Additional conditions:
Condition*=directives, etc.
From this, systemd builds a dependency graph and:
- Starts units in parallel where possible.
- Ensures required units start before dependents.
- Avoids unnecessary services if nothing depends on them.
Example idea (not full syntax):
sshd.servicemight:After=network.targetWants=network.target
This says: “I want the network up, and I should only start after the network is essentially ready.”
Comparison to Traditional SysV init (Conceptual)
You don’t need to know all the details of SysV init to understand systemd, but it helps to see what changed conceptually:
- SysV init:
- Uses shell scripts in
/etc/init.d/. - Uses numeric runlevels (
0–6). - Startup order is controlled by file name prefixes (
S10,S20, etc.). - Limited dependency handling and little parallelism.
- systemd:
- Uses declarative unit files.
- Uses targets instead of numeric runlevels.
- Explicit dependencies and robust parallel startup.
- Integrated logging, cgroup-based supervision, and more.
Most distributions still provide compatibility so old SysV scripts can be managed by systemd, but native unit files are the “modern” way.
systemd and cgroups: Process Management
systemd relies heavily on Linux control groups (cgroups) to:
- Group all processes belonging to a particular service.
- Track and control resource usage per service:
- CPU
- Memory
- I/O
- Cleanly stop or restart a service by affecting all its processes.
This solves the classic problem where a service script stops only the main process but leaves helper processes running. With cgroups, systemd knows every process in a unit’s group and can terminate them together.
The Role of Targets: Modern “Runlevels”
systemd uses targets to represent system states or goals. Targets are units of type .target that:
- Group other units together.
- Express what should be active for a certain system state.
Examples:
multi-user.target: multi-user, non-graphical system (similar to runlevel 3 on some distros).graphical.target: multi-user + graphical session (similar to runlevel 5).rescue.target: single-user, minimal environment for recovery.
Targets are composed of dependencies on services, mounts, and other units. You’ll manage them with systemctl in the next chapter; here just remember:
- Targets = named sets of units representing system states.
Why Many Distributions Adopted systemd
Most major distributions (e.g., Debian, Ubuntu, Fedora, RHEL, openSUSE, Arch Linux) use systemd as their default init system. Reasons include:
- Faster boot with parallelism and on-demand activation.
- Simpler service supervision:
- Automatic restarts on failure.
- Integrated logging.
- Uniform tools across systems:
systemctlfor service and unit management.journalctlfor logging.- Better resource control per-service with cgroups.
- Extensibility: timers, path units, socket activation, etc. all fit into the same model.
Some Linux distributions intentionally avoid systemd for philosophical or technical reasons, but in practice, if you administer Linux servers or desktops, you’re very likely to deal with systemd.
Where You’ll Interact with systemd as an Admin
In day-to-day work, systemd matters because you’ll commonly:
- Start/stop/restart services (daemons).
- Enable/disable services at boot.
- Check service status and logs.
- Change the system’s default boot target (e.g., graphical vs multi-user).
- Diagnose boot issues and dependency problems.
In the following chapters of this section, you’ll learn:
- How to manage services with
systemctl. - How boot targets work.
- How to use
journalctlfor logs. - How to define your own custom services.
For now, the key takeaway is that systemd is the central component coordinating how your Linux system starts, runs its services, and shuts down, using a rich, dependency-aware model built around units.