A server has finished booting, but how did its web server, SSH daemon, scheduled jobs, and mounted filesystems become available? On many Linux distributions, the answer involves systemd: the manager that coordinates much of the system after the kernel starts userspace.
In the previous lesson, Linux services, daemons, and background processes, we separated a managed workload from the program doing the work. This lesson explains the management layer around those workloads.
systemd is a system and service manager. Its system instance normally runs as PID 1. It represents managed resources as units, uses dependencies to coordinate them, and groups units through targets. A service is one kind of unit; systemd is not the Linux kernel.
- 🎯 What You’ll Learn
- 🐧 Where systemd Fits in Linux
- 🧩 What Is a Unit?
- 🚦 Targets Coordinate Groups of Units
- 🔗 Ordering Is Different from Requiring
- 📄 Reading a Service Definition
- 🧪 Mini Lab: Map a Service to Its Unit
- 1. Identify the initial process
- 2. Find installed service definitions
- 3. Compare definition and current state
- 4. Inspect dependency context
- ⚠️ Common Mistakes
- ✅ Knowledge Check
🎯 What You’ll Learn
- Where systemd fits into startup.
- How services, sockets, timers, mounts, and targets differ.
- Why ordering and dependency requirements are separate.
- How to inspect your own system without changing it.
🐧 Where systemd Fits in Linux
The kernel manages CPU scheduling, memory, devices, and other core operating-system facilities. Userspace programs run on top of that foundation. The initial userspace process has PID 1; on a systemd-based installation, that role is normally handled by systemd.
A simplified startup path looks like this:
Firmware → Boot loader → Kernel / early userspace → systemd → UnitsReal startup is more detailed. An initial RAM filesystem may prepare storage before the main root filesystem is used, and some installations use systemd there too. The useful beginner point is that the kernel does not read a list of web servers and start them for you. A userspace manager coordinates those workloads.
Linux does not require systemd. Some distributions use other init systems, and a container may run an application as PID 1. If a command says the system was not booted with systemd, first check the environment rather than assuming the installation is broken.
🧩 What Is a Unit?
A unit is an object systemd knows how to manage. Its suffix tells you what kind of object it is. A unit name is a management identifier, not necessarily the name of an executable.
| Unit type | What it represents | Example use |
|---|---|---|
.service | A managed workload | A web server or a finite maintenance task |
.socket | An activation socket | Starting a service when a connection arrives |
.timer | A time-based trigger | Activating a cleanup job on a schedule |
.mount | A filesystem mount | Making a filesystem available at a path |
.target | A grouping and synchronization point | Coordinating a system startup state |
A timer usually triggers another unit; it is not the program that performs the scheduled work. Similarly, a socket and the service it activates are separate objects. This is why looking only at running service units does not reveal every activation mechanism.
🚦 Targets Coordinate Groups of Units
A target does not have to launch a permanent process. It expresses a useful grouping in the dependency graph. For example, multi-user.target commonly represents a non-graphical multi-user environment, while graphical.target adds the graphical login environment.
You can ask which target is configured as the default:
systemctl get-defaultThis reports a configuration choice. It is not an application health check. Reaching a target does not prove that your database accepts queries or your website returns the correct page.
Targets are useful for reading how the machine is organized. Avoid experimenting with target switching on a remote server: stopping units outside a target can interrupt the very session you are using.
🔗 Ordering Is Different from Requiring
Two questions must be answered separately: Should another unit be activated? and Which unit must finish starting first?
Wants=pulls another unit into the activation transaction with a relatively weak dependency.Requires=expresses a stronger requirement, with additional failure and stop relationships.After=orders startup when both units are involved; it does not itself request activation of the other unit.
These settings are often combined. An ordering statement alone does not ensure a remote database is ready, and After=network.target does not mean the internet is reachable. Applications still need suitable readiness checks, connection handling, and retries. See the unit configuration reference for exact dependency semantics.
📄 Reading a Service Definition
Inspect a real installed service before trying to write your own. In the following commands, replace example.service with a name found on your machine.
systemctl cat example.serviceYou may see a main unit file and additional drop-in files. Read all of them: an administrator override can change the behavior described by the packaged file.
Three section names help orient you:
- [Unit] describes the unit and its relationships.
- [Service] describes how the service workload is executed and supervised.
- [Install] describes enablement relationships used when enabling the unit.
For example, ExecStart= identifies a startup command. A setting such as WantedBy=multi-user.target describes how enablement can attach the service to that target. Merely seeing this line in a file does not mean the service has already been enabled.
🧪 Mini Lab: Map a Service to Its Unit
Environment: a Linux system using systemd. These steps inspect state; they do not restart or reconfigure services.
1. Identify the initial process
ps -p 1 -o pid,comm,argsLook at the command associated with PID 1. If this is a container or a different init system, the rest of the lab may not apply.
2. Find installed service definitions
systemctl list-unit-files --type=serviceChoose one known service from the output. Names vary: an SSH service may be called ssh.service or sshd.service.
3. Compare definition and current state
systemctl cat example.service
systemctl status example.service --no-pagerThe first view explains configuration. The second describes what the manager currently reports. Keep these questions separate: “What is supposed to run?” and “What happened when it ran?”
4. Inspect dependency context
systemctl list-dependencies example.serviceUse the tree as a starting point for exploration. It is not a promise of application readiness or a complete account of every external dependency. Press q to leave a pager when one appears.
⚠️ Common Mistakes
“systemd and systemctl are the same thing.” systemd is the manager; systemctl is a command-line client used to talk to it.
“Every unit has a daemon.” Targets group other units, timers trigger work, and some services perform a task and exit.
“An enabled service must be running.” Enablement concerns activation configuration. A service can be enabled and failed, or disabled and running because it was started manually.
“Editing a packaged file is the best customization method.” Package updates can replace vendor files. Learn the drop-in mechanism before making lasting overrides.
✅ Knowledge Check
- Why is a target different from a daemon?
- Does
After=start the named dependency? - Which tool shows a unit file and its drop-ins?
🎓 Check Your Answers
1. A target groups and coordinates units; it need not run a daemon. 2. No: it defines ordering when both units participate. 3. systemctl cat.
Think of systemd as the manager, units as the managed objects, and targets as coordination points. Once you can read those relationships, service behavior becomes easier to investigate.
Continue learning: next, practice managing services with systemctl, then learn to read service logs with journalctl.
