systemd replaced the old SysV init scripts in most major distros over the 2010s, and while its scope (arguably too broad, according to some vocal critics) remains debated in Linux circles, its unit-based model for managing services is something every Linux user eventually needs to understand.
What a Unit File Looks Like
[Unit] Description=My Application Server After=network.target postgresql.service [Service] Type=simple User=myapp WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/venv/bin/python /opt/myapp/server.py Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
Managing Services with systemctl
sudo systemctl daemon-reload # after editing a unit file sudo systemctl enable --now myapp # enable at boot AND start now sudo systemctl status myapp sudo systemctl restart myapp # Follow live logs for a specific unit journalctl -u myapp -f # See boot time breakdown by unit (useful for slow-boot debugging) systemd-analyze blame
Targets: The Runlevel Replacement
Targets replace the old numbered runlevels with named states: multi-user.target (normal non-graphical operation), graphical.target (desktop environment), rescue.target (single-user recovery mode). systemctl get-default shows the current boot target.
Why It Matters Beyond Services
systemd also owns logging (journald), device management (udev is integrated), network configuration on many distros (systemd-networkd), and DNS resolution (systemd-resolved) — understanding the unit model pays off well beyond just starting and stopping daemons.