systemd is the init system and service manager used by most modern Linux distributions. If you learn what it does as PID 1 and how units work, day-to-day operations become much easier to reason about.
Table of Contents
This post starts the series with the concepts you need before managing units in production.
Core Concepts
- What PID 1 does
- Why Linux moved from SysV init to systemd
- SysV init vs systemd at a glance
- The systemd unit model
- How to verify systemd on your host
Series Navigation
What PID 1 does
PID 1 is the first userspace process the kernel starts, and every other process is ultimately managed through that lifecycle. On systemd-based systems, systemd is PID 1 and orchestrates startup ordering, dependency handling, and shutdown behavior.
In practice, this means:
- Services are started and supervised through unit definitions
- Dependencies are declared explicitly instead of inferred by script order
- Failures can be restarted or isolated with policy-driven behavior
- Logs and metadata can be queried centrally with journal tools
Why Linux moved from SysV init to systemd
SysV init was script-driven and worked well for earlier Linux generations, but it became harder to scale as systems grew in complexity. systemd introduced declarative units, richer dependency semantics, and parallelized startup that better matches modern workloads.
Common drivers for the shift:
- Faster boot through parallel activation where dependencies allow it
- Better observability with consistent state and structured logging
- More predictable automation with standard unit lifecycle commands
- Unified service, socket, timer, mount, and target management
SysV init vs systemd at a glance
Area SysV init systemd
----------------------- ---------------------------------------- ----------------------------------------------
Service definition Shell scripts in /etc/init.d Unit files in /usr/lib or /etc/systemd/system
Control interface service/chkconfig/update-rc.d systemctl
Boot grouping Runlevels (0-6) Targets (multi-user.target, graphical.target)
Dependency handling Script order and naming conventions Explicit Wants/Requires/After/Before
Startup model Mostly serial Parallel where dependency graph allows it
Failure handling Script-specific Built-in restart policies and unit state model
Logging Syslog/text logs journald with structured metadataIf you are coming from SysV, the key mindset change is that systemd treats service startup as a dependency graph instead of a linear script list.
The systemd unit model
A unit is a typed configuration object that tells systemd how to manage part of the system lifecycle. You will work most with service units, but several other unit types are foundational:
servicefor daemon or one-shot process executiontargetfor grouping units into desired system statessocketfor socket activation and on-demand startuptimerfor scheduled execution similar to cron use casesmountandautomountfor filesystem lifecyclepathfor triggering actions when files or paths change
Later in this series, dedicated posts cover systemd-networkd, systemd-resolved, and systemd-timesyncd so you can understand how systemd extends into networking, DNS, and time sync.
How to verify systemd on your host
Use these commands to confirm what init system is active and what version you are running.
ps -p 1 -o pid,comm,args
systemctl --versionsystemctl --version also reveals build features and linked components, which is useful when features vary across distributions.
Series navigation
In this series, each post builds on the previous one, so reading in order gives the cleanest path from fundamentals to production hardening.
Next in this series
Next, we move from concepts to daily operations with systemctl so you can start, stop, enable, inspect, and troubleshoot units confidently.
systemctl Essentials: Start, Stop, Enable, and Inspect Units