systemd

systemd is PID 1 on nearly every current Linux distribution: it starts services, supervises them, manages their dependencies, handles logging through the journal, and covers timers, mounts, sockets, and network configuration.

What it replaced, and why it won

SysV init ran shell scripts in a numbered order. Each script implemented start, stop, and status itself, so behaviour varied between packages, and “is this running” was answered by a PID file that could be stale. Ordering was an approximation of dependency, and boot was serial because nothing knew what could run in parallel.

systemd declares dependencies (After=, Requires=, Wants=), so the ordering is derived rather than asserted, and independent services start in parallel. It tracks processes with cgroups rather than PID files, which means it genuinely knows what is running and can reliably kill everything a service spawned — a real improvement over a stop script that misses a forked child.

The unit file is the other gain. A dozen lines of declaration replace a hundred lines of shell, and restart policy, resource limits, and sandboxing become settings rather than code.

What is worth using

Restart policies. Restart=on-failure with RestartSec handles the crash-loop case that would otherwise need a supervisor. Setting StartLimitBurst prevents a genuinely broken service from restarting forever.

Sandboxing directives are underused and cheap. ProtectSystem=strict, PrivateTmp=true, NoNewPrivileges=true, and ProtectHome=true meaningfully constrain a compromised service, and they are a few lines in a unit file rather than a policy to write. This is the highest security return per unit of effort available on a Linux host.

Timers are a better cron: they log to the journal, have dependency handling, and support randomised delays so a fleet does not all fire at once.

The complaints

The scope objection is real. systemd absorbed functions that were separate programs, and the resulting coupling means distributions depending on it cannot easily substitute pieces. Whether that is bad architecture or reasonable integration is a genuine disagreement rather than a settled question.

The binary journal is the other. journalctl is more capable than grepping text — filtering by unit, boot, or priority is properly structured — and the log is not readable without the tool, which matters when recovering a broken system. Shipping to rsyslog and onward is the usual answer.

See also: rsyslog, chrony, nftables, and Linux administration in datacenters.