Table of Contents
Introduction
Systemd is the standard system and service manager on most modern Linux distributions. It starts early in the boot process, brings up services, manages system resources, and provides a unified way to control what runs on your machine. In this chapter you will see what systemd is, why it exists, and how it changes the way you manage services compared to older tools like init and SysV. Later sections will cover the specific tools and concepts, such as systemctl, boot targets, and logs, in more detail.
What systemd Replaces
Traditional Linux systems used an init system such as SysV init. That model relied heavily on shell scripts stored in directories like /etc/init.d, which were called in a certain order during boot and shutdown. Services were enabled or disabled by symlinks in runlevel directories, and each script implemented its own way of starting, stopping, and reloading a service.
Systemd replaces this older style with a more structured system built around declarative unit files instead of ad hoc scripts. Instead of runlevels, it uses targets. Instead of each service script deciding how to log, systemd provides a unified journal. Commands such as service or chkconfig are replaced by systemctl, which offers a single interface for managing units.
You do not need to know all of the details of SysV init to use systemd, but it helps to understand that systemd is designed as a more integrated and feature rich replacement for these older mechanisms.
Systemd as PID 1
When a Linux system boots, the kernel eventually starts one user space process as the first process on the system. This process always has process ID 1, written as PID 1. Systemd usually runs as PID 1, which means it is responsible for starting all other user space processes, monitoring them, and handling their exit states.
Because systemd runs as PID 1, it has some special responsibilities. It must handle signals from the kernel related to shutdown and reboot, such as when you press the power button on a physical machine. It must reap zombie processes that have no parent. It must also provide a consistent environment for other services, including basic mounts, device management, and initial configuration that is required before higher level services can run.
Unlike a simple init script runner, systemd tracks processes more closely. Each service is placed in its own cgroup, which allows systemd to monitor all the processes that belong to that service. If a service is stopped or restarted, systemd can terminate or replace all processes that are part of it, not just the main one.
Units and the Unit Model
The core abstraction in systemd is the unit. A unit is a configuration object that systemd understands and can manage. There are several different unit types, such as services, sockets, targets, timers, and others. Each unit type describes a different kind of thing that systemd can start, stop, or otherwise control.
Every unit is typically defined in a unit file with a name like example.service or network.target. A normal Linux user usually interacts with services most often, but the other types make it possible for systemd to describe both ordering and dependencies clearly.
Systemd uses these unit files to build a dependency graph. This graph defines which units must start before others, what can start in parallel, and which units are required or wanted for specific system states. As a result, systemd can start your system faster and more reliably, because it understands the relationships among services rather than relying solely on numeric order.
A unit is not just a service. It is any object that systemd can manage, including services, sockets, timers, devices, mounts, automounts, targets, and more.
Service Management Concepts
Services under systemd are represented by units of type service. Each service unit defines how a daemon or long running program should be started, stopped, reloaded, and restarted on failure. Systemd also records the current state of a service, such as active, inactive, failed, or activating.
A key difference from older init systems is that systemd does not depend on hand written shell scripts for each service. Instead, service definitions use a common configuration syntax and a straightforward set of directives. This makes it much easier to manage large numbers of services in a consistent way.
Systemd tracks the lifecycle of each service. It can automatically restart services after a crash, delay the start of certain services until prerequisites are met, or start services on demand when a socket or path is accessed. This fine grained control is possible because systemd manages services based on their explicit configuration rather than implicit behaviors.
Parallelization and Dependencies
Traditional boot systems often started services in a mostly sequential order, which could make boot slow. Systemd uses a dependency graph to parallelize startup. If two services do not depend on each other, systemd can start them at the same time. If one service requires that another be running first, systemd encodes that requirement in the unit configuration.
In practice, this means that systemd can bring a system from power on to a multi user or graphical state more quickly. It also means that service management is more predictable. When you start or stop a specific service, systemd will automatically bring up or tear down other units that are required or ordered relative to that service.
Systemd units distinguish between hard requirements and weaker associations. A required dependency must be present for a unit to start. A wanted dependency is more of a recommendation, useful for building more flexible boot sequences. These relationships are not described in detail here, but they are an essential part of how systemd organizes the system.
Targets and System States
Earlier systems used runlevels to describe system states, such as single user mode or full multi user mode. Systemd replaces runlevels with targets. A target is a special type of unit that groups other units together, representing a particular state the system should achieve.
For example, there is usually a target that represents the normal graphical desktop environment, one for the multi user text based environment, and one for rescue or emergency situations. When systemd starts a target, it activates all units that are part of that target or required by it. This is how systemd coordinates many services into a complete system state such as a fully running server or a basic rescue shell.
Because targets are units like any other, you can create custom ones that represent particular combinations of services you care about. This flexibility allows administrators to define their own system states without modifying the core of systemd itself.
Logging and the Journal
Systemd includes a component called the journal, which collects logs from the kernel, from system services, and from other parts of user space into a single structured store. Instead of relying entirely on plain text files under /var/log, systemd uses a binary format for the journal which can be queried in flexible ways.
This unified logging approach makes it easier to see what happened during system startup or why a particular service failed to start. Since the journal is aware of systemd units, it can show you the logs that correspond exactly to a specific service, rather than requiring you to guess which file or tag contains the information.
The journal works closely with other systemd components, but it does not replace all traditional logging. Many systems will still ship logs to text files or external log collectors. For basic administration, however, the journal provides a single, powerful interface that is consistent on any system that uses systemd.
Configuration Locations and Overrides
Systemd reads unit files from several locations. Distributions usually provide default unit files under system directories, and administrators can place custom or modified unit files under dedicated configuration paths. This separation allows the base system to update its units while still letting you override or extend behavior in a safe way.
Instead of editing vendor supplied unit files directly, systemd encourages the use of override files. An override file lets you change specific options for a unit without replacing the entire original file. This method reduces the risk that your changes will be lost during package upgrades and makes it easier to see exactly what has been customized.
Understanding where systemd looks for units and how it merges configuration is important when you start creating your own services or adjusting existing ones. The details of these paths and override mechanics are covered when you work with actual unit files, but the central idea is that systemd is designed to be configurable without sacrificing maintainability.
Systemd in Different Distributions
While systemd behaves similarly across distributions, there can be small differences in how it is integrated. Some distributions rely heavily on systemd features such as timers, journaling, and network management, while others use systemd primarily for service management and boot, leaving other tasks to separate tools.
Despite these differences, the basics of systemd service management, targets, and logging remain consistent. Once you understand systemd on one modern Linux distribution, you can usually transfer that knowledge easily to another.
Systemd has largely become the standard in mainstream Linux distributions. Some specialized or minimal systems may still use alternative init systems, but for most desktop and server usage, you will encounter systemd. This chapter prepares you to understand and work within that common environment, while later chapters build on these concepts for more advanced administration tasks.
Why Systemd Matters for Administrators
From an administrator’s perspective, systemd simplifies several tasks. You use a single tool to start, stop, enable, and inspect services. You have a clear model of system states through targets. You gain better visibility into service behavior with the journal and more robust control over how services behave when they fail.
At the same time, systemd introduces its own learning curve. It is more complex than simple init scripts, but that complexity is organized around explicit configuration, consistent interfaces, and integrated features. For day to day work, most of your interaction with systemd will center on managing services and inspecting logs. The foundational concepts introduced in this chapter give you the mental model needed to use the specific commands and techniques that follow.