systemd — The Complete Guide
turn any script into a service that auto-starts, self-heals, and ships logs — in 25 lines of YAML
systemd is the process and service manager of most modern Linux distributions (Ubuntu, Debian, CentOS, Fedora, Arch — all of them). Without systemd, every time you wanted a script to start automatically at boot, restart if it crashes, and get bounded RAM/CPU — you had to write a lot of dirty code with cron, screen, supervisord and init.d. With systemd, all of that is a small INI-style text file with 10-20 lines and one command. For me (Elad) on the Hetzner VPS, systemd manages all 13 of my microservice agents: each is a separate systemd unit, auto-starts, ships logs centrally to journalctl, and restarts itself if it crashes. systemd-timer also replaces my cron with clearer syntax and execution history, and systemd-resolved handles DNS. It is not the most popular tool among Unix-philosophy purists (some prefer classic init scripts), but the reality is that if you're in production Linux — you're using systemd. This guide will show the parts you'll use 90% of the time: writing service units, managing them via systemctl, and reading logs in journalctl.
What this guide covers
What is systemd? The process manager
PID 1 — the first process, responsible for everything else
systemd is what Linux runs first after the kernel boots — it is process number 1 (PID 1), and it is responsible for bringing up every other service the server needs. The classic 'init system' has gradually been replaced by systemd in most distributions since 2015, and it offers far more than 'just run scripts in order X': dependency management between services, parallelism (services that don't depend on each other start together), automatic health checks, resource limits, and central log management. It is somewhat controversial in the Linux community (some argue it's 'too big' and violates Unix philosophy), but in practice — it's what you'll meet on every production server.
Service Unit: the file that defines a service
20 lines that turn a script into infrastructure
A service unit is a simple INI file describing how to run your service. Three main sections: [Unit] (description and dependencies), [Service] (how to run — command, user, restart policy), and [Install] (where in the boot order to enable). Each of my 13 agents is defined in such a file under `/etc/systemd/system/`.
systemctl: the commands you'll use every day
start, stop, status, enable, disable
systemctl is the CLI for managing systemd. Most of what you do is very simple commands you'll repeat dozens of times a day. Here's the set that covers 95% of the time.
journalctl: central logs, fast queries
All logs from all services — in one place, with queries
journalctl is the tool for reading logs systemd collects. Anything your services write to stdout or stderr goes there automatically, with rich metadata (precise timestamp, PID, unit, user). You can search by any of them, filter by time range, follow in real time — all in one tool.
Timers: the cron of 2026
Schedule tasks with history, visibility, and better than cron
systemd-timers is the modern replacement for cron. Instead of one file with archaic syntax (`* * * * *`), each scheduled job is two files: `myjob.service` (what to do) and `myjob.timer` (when). Advantages over cron: full history (`journalctl -u myjob.timer`), restart on failure, advanced features like 'run weekly at 2am only if the server was up then'.
Advanced: sandboxing, resource limits, secrets
Turns systemd into a lightweight Docker substitute in many cases
One of systemd's modern features is the ability to isolate services without Docker — through kernel mechanisms (namespaces, cgroups, capabilities). If your project doesn't strictly need containerization (you don't need to build an image to share with others), systemd can give you 80% of Docker's isolation in a few lines.
