Table of Contents
Introduction
Systemd is the default system and service manager on most modern Linux distributions. It is responsible for starting the system, managing services, and keeping essential parts of the operating system running. In many distributions, systemd replaces older init systems such as SysV init and Upstart. Understanding what systemd is at a conceptual level will help you make sense of later chapters that focus on specific systemd tools and commands.
Systemd as a System and Service Manager
At its core, systemd is a program that starts early in the boot process and remains running for the entire lifetime of the system. It starts and stops services, tracks their status, and controls how they interact with each other. Services in this context are long running programs, sometimes called daemons, that provide functionality such as logging, networking, or web serving.
Systemd manages these services using configuration files that describe how and when each service should start. These configuration files are called unit files. Systemd uses them to determine dependencies between services, startup order, and actions to take when services exit or fail.
When the system powers on, the kernel eventually hands control to systemd, which then brings the rest of the system to the desired state. This can be a graphical desktop environment, a text console, or a minimal system intended only to run background services.
Systemd as PID 1
Every process running on a Linux system has a process identifier, or PID. The very first user space process that the kernel starts is given PID 1. On systems that use systemd, systemd occupies PID 1.
Being PID 1 gives systemd several special responsibilities. It must:
Handle the starting and stopping of other processes that make up the system.
Reap orphaned processes, which means cleaning up processes that have finished running but have not yet been acknowledged by their parent.
React to certain signals and events that control system states, such as reboot, shutdown, and poweroff.
Because PID 1 is so central, if it fails the whole system is usually unusable. This is one reason systemd is designed to be robust and to monitor child processes closely.
Units and the Idea of a Unified Manager
Systemd introduces the idea of units as a way to represent different system resources. A unit is a configuration object that systemd knows how to manage. Services are one type of unit, but there are others such as sockets, timers, targets, devices, mounts, and more. Each unit type is handled according to its own rules, but all are controlled by the same overarching systemd process.
The goal is to have a unified manager for many aspects of the system. Rather than having separate ad hoc tools for services, mounts, and timers, systemd integrates control of these into one framework. Later chapters will explore how to manage services specifically, so here it is enough to recognize that systemd looks at the system as a collection of units that it activates and supervises.
Important: In systemd terminology, a "unit" is the fundamental object that systemd manages. Services are just one kind of unit, represented by .service unit files.
Parallel Startup and Dependency Handling
An important design goal of systemd is faster and more predictable system startup. Traditional init systems tend to start services in rigid sequences, often controlled by numbered scripts. Systemd, by contrast, reads dependencies between units from their configuration and uses that information to start as many units in parallel as possible while still respecting ordering requirements.
For example, a service that depends on networking will not be started until the units responsible for network configuration are considered ready. However, it can start in parallel with other units that do not depend on networking. This dependency driven, parallel approach is a key characteristic of systemd.
Systemd also keeps track of the states of units. It knows whether a unit is active, inactive, failed, or in some intermediate state. When something fails to start, systemd records this so that administrators can inspect the situation later.
Systemd as a Collection of Tools
Although systemd itself runs as PID 1, the systemd project includes many related programs and libraries. These tools interact with the main systemd process to control units, inspect system state, and access logs.
Some of the most visible tools are:
systemctl to control and query systemd units.
journalctl to view logs from the systemd journal.
Other components handle network configuration, logging, login sessions, and more. The details of these tools belong to later sections. For now, the important point is that the word “systemd” often refers not just to the PID 1 process but to a broader ecosystem of utilities that integrate with it.
Systemd and the Traditional init System
Historically, Linux used simpler init systems, often based on a program called init and a collection of scripts executed one after another. Systemd was created to address various limitations of these systems, such as slow startup, fragile script ordering, and limited process supervision.
Systemd replaces many of those scripts with declarative unit files. Declarative means that the configuration describes what should happen, not how to do each step procedurally. Systemd then interprets this description and applies it. This shift from scripts to configuration is one of the defining differences between systemd and older init systems.
Because systemd takes over the role of init, many distributions treat it as a central component. Service management, logging, and system startup are closely tied into it. This integration has made systemd widely adopted, though some distributions continue to use alternatives.
Controversy and Adoption
Systemd has been adopted by many popular distributions such as Debian, Ubuntu, Fedora, and others. It is often the default on general purpose systems. However, systemd also generated considerable debate in the Linux community.
Critics argue that systemd is complex, that it does too many things, and that it goes against the traditional philosophy of small, focused tools. Supporters emphasize its practical benefits, including faster boot times, strong process supervision, advanced logging, and consistent management interfaces across distributions.
From a learner’s perspective, the most important fact is that if you use a common modern distribution, you will likely interact with systemd regularly, especially when working with services and troubleshooting. Whether or not you agree with its design, knowing how it works is essential.
Where systemd Fits in the System
Systemd sits between the kernel and user applications. After the kernel initializes hardware and basic low level functionality, it invokes systemd as PID 1. Systemd then starts the base services that other programs depend on. Graphical environments, login prompts, network facing daemons, and user sessions are all either started directly by systemd or are children of processes that systemd manages.
When the system shuts down or reboots, systemd again coordinates the process. It stops services in a controlled way, unmounts filesystems, and finally tells the kernel to power off or reboot. This central position at both startup and shutdown means systemd has a complete view of the system’s lifecycle.
You can think of systemd as the conductor of an orchestra. The kernel provides the stage and instruments, the services and daemons provide the musical parts, and systemd decides when and how each part should come in and out to produce a working system.
Summary
Systemd is the modern system and service manager on many Linux systems. It runs as PID 1, starts and supervises services, manages dependencies between system components, and provides a unified framework for controlling a wide range of system resources. It replaces older init systems with a more declarative, integrated approach, and serves as the foundation for the service management tasks covered in the rest of this section.