Systemd
systemd manages system boot, services, timers, targets, and dependencies.
It matters because it turned service supervision, boot ordering, unit composition, and runtime inspection into a more coherent operating model across much of the Linux world. For day-to-day administration, it is less a single daemon than the vocabulary through which many distributions now describe system behavior.
Why it matters
- Standardizes service definitions across Linux fleets.
- Supports robust restart and dependency policies.
- Integrates with logging through
journald.
Core concepts
- Units describe services, timers, mounts, sockets, and other managed objects.
- Targets group system states in a way that replaced older runlevel thinking.
- Dependency and ordering directives make service relationships explicit.
- Timers often replace ad hoc cron usage when jobs should be supervised as part of the service model.
Operational strengths
- Restart policies and dependency handling improve service resilience.
systemctland related tooling make runtime inspection consistent.- Unit files are reviewable text, which makes them a good fit for infrastructure-as-code workflows.
Common admin tasks
- Start/stop/restart services with
systemctl. - Enable services at boot with
systemctl enable. - Inspect service health with
systemctl status.
Pressure points
- The model is powerful, but troubleshooting requires understanding unit interactions rather than only reading one init script.
- Poorly designed service files can hide restart loops, startup races, or dependency errors.
- Centralization improves consistency, but it also means operators need to be fluent in systemd’s abstractions.