systemd, Services & Process Management
Understand systemd as PID 1, read and write unit files, control services with systemctl, and use signals to manage running processes correctly.
Learning Objectives
- → Explain systemd's role as PID 1 and how it supersedes traditional SysV init scripts
- → Read and write a basic systemd unit file
- → Use systemctl to start, stop, enable, and check the status of a service
- → Describe Linux process states and how signals (SIGTERM, SIGKILL, SIGHUP) control processes
- → Explain the relationship between systemd, journald, and targets
PID 1: The First Process
The kernel starts exactly one process directly: PID 1. On virtually every modern distribution, that process is systemd — it spawns and supervises every other process on the system, directly or indirectly, and is the last process to exit on shutdown.
From SysV init to systemd
Older distributions used shell scripts in /etc/init.d/ to start and stop services, executed sequentially by "runlevel." systemd replaced this with declarative unit files and parallel startup, dramatically cutting boot time and giving every service a consistent way to declare dependencies, restart policy, and logging.
Anatomy of a Unit File
[Unit]
Description=My Web App
After=network.target
[Service]
ExecStart=/usr/bin/mywebapp
Restart=on-failure
User=appuser
[Install]
WantedBy=multi-user.target
- [Unit] — metadata and ordering (
After=,Requires=) - [Service] — how to run it:
ExecStart=is the command systemd executes;Restart=controls auto-restart behavior;User=drops privileges - [Install] — which target pulls this unit in when enabled (
WantedBy=)
Controlling Services with systemctl
| Command | Effect |
|---|---|
systemctl start nginx |
Start now, this boot only |
systemctl stop nginx |
Stop now |
systemctl enable nginx |
Symlink into the target so it starts at every future boot |
systemctl enable --now nginx |
Enable and start in one step |
systemctl status nginx |
Show current state plus the most recent log lines |
systemctl daemon-reload |
Reread unit files after hand-editing one |
Targets: systemd's Runlevels
multi-user.target (normal server boot, no GUI) and graphical.target (multi-user plus a display) replace the old numbered runlevels. WantedBy=multi-user.target is why most server-side services enable against it.
Process States and Signals
| State | Meaning |
|---|---|
| R (Running) | Actively executing or ready to run |
| S (Sleeping) | Waiting on an event (I/O, timer) |
| Z (Zombie) | Exited, but the parent hasn't reaped its exit status yet |
| T (Stopped) | Suspended, e.g. by SIGSTOP |
| Signal | Number | Effect |
|---|---|---|
| SIGHUP | 1 | Traditionally: reload configuration without restarting |
| SIGINT | 2 | What Ctrl+C sends — interrupt |
| SIGKILL | 9 | Immediate termination — cannot be caught, blocked, or ignored |
| SIGTERM | 15 | Graceful termination request — the process can catch this and clean up first |
Always try SIGTERM before SIGKILL: SIGKILL gives the process no chance to close file handles, flush buffers, or release locks.
journald: Where systemd Sends Logs
journalctl -u <service> shows only that unit's history; journalctl -f follows new entries live, like tail -f; journalctl --since "1 hour ago" filters by time.
Common Pitfalls
- Forgetting
systemctl daemon-reloadafter hand-editing a unit file — systemd keeps running against the old definition until you reload - Reaching for
kill -9(SIGKILL) as a first resort instead of a plainSIGTERM, denying the process any cleanup Restart=alwayswith noRestartSec=delay turning a crashing service into a tight, journal-flooding restart loop
The [Service] section is where systemd learns exactly how to run your program.
Which unit-file directive specifies the command systemd runs to start the service?
SIGKILL cannot be caught or ignored by the target process; SIGTERM can.
Which signal allows a process to clean up (close files, save state) before exiting?
Enabling and starting a service are two separate actions unless you combine them with --now.
Which systemctl subcommand makes a service start automatically at every future boot, without starting it right now?
💪 Exercises & Challenges
systemd, Services & Process Management MCQ
Test your understanding of systemd, Services & Process Management.
Design a systemd Unit File
Write a complete unit file for a Python web app located at /opt/webapp/app.py, run as user 'webapp', that should restart automatically on failure, start after networking is up, and be enabled for the
Stop the Restart Storm
A service `payments.service` keeps entering a restart loop every 2 seconds, filling the journal with thousands of entries per hour and masking the real crash reason. 1. Which systemctl subcommand wou