systemd guide

What systemd does

systemd is PID 1 on most Linux servers. It mounts filesystems, brings up the network, starts daemons, tracks dependencies between them, and restarts failed services according to unit configuration. Logging goes to the journal (journald), queried with journalctl.

Unit types

• .service — a daemon or one-shot command (nginx, ssh, your app)
• .socket — socket activation; starts a service on incoming connections
• .timer — scheduled jobs (systemd's cron replacement)
• .target — grouping unit (like runlevels: multi-user.target)
• .mount / .automount — filesystem mounts managed by systemd

How boot and service startup work

At a high level, the workflow is:

1. Kernel hands off to PID 1 — systemd becomes the init process
2. Default target — systemd activates default.target (usually multi-user.target or graphical.target)
3. Dependency resolution — units listed in Wants=, Requires=, After=, and Before= determine start order
4. Parallel startup — independent units start concurrently once dependencies are met
5. Service activation — ExecStart= runs the main process; systemd tracks the PID and reports state
6. Steady state — running services are monitored; failures trigger Restart= policies; timers fire on schedule

systemctl enable creates symlinks so a unit starts at boot. systemctl start starts it immediately. You often need both for production services.

Unit file locations

• /usr/lib/systemd/system/ — package-installed units (do not edit directly)
• /etc/systemd/system/ — administrator overrides and custom units
• systemctl edit myservice — drop-in overrides under /etc/systemd/system/myservice.service.d/

Key directives in a service unit

• [Unit] — Description=, After=network.target, Wants=
• [Service] — Type=, ExecStart=, User=, Restart=, Environment=
• [Install] — WantedBy=multi-user.target (enable target)

Triage: what failed?

When something is wrong but you do not know which unit yet, start with a system-wide view of failures:

Both list every unit in failed state — services, mounts, timers, and more — in one shot. That is faster than checking services one at a time. Pick a failed unit, then drill down with systemctl status UNIT and journalctl -u UNIT. Clear the failure bit after fixing with systemctl reset-failed.

Timers vs cron

A .timer unit triggers a paired .service unit on a calendar or monotonic schedule. Timers integrate with journald, support randomized delays, and respect dependency ordering — useful for maintenance jobs on systemd-native distros (see also the Cron lab).

Non-provileged user

systemd also works at the user level. It runs a separate, unprivileged service manager for each logged-in user. This allows the user to start, stop, and manage background tasks like daemons or automated scripts without needing root/administrator privileges.

User service files are placed in the user's home directory ~/.config/systemd/user/ rather than system directories like /etc/systemd/system/. The user's systemd starts when the user logs in and is killed when the user logs out.

To manage systemd as non-privileged user, the user only need to pass the --user flag

• systemctl --user start [service-name] — Start a service
• systemctl --user start [service-name] — Enable a service on login
• systemctl --user start [service-name] — Check status

Learning resources

• systemd.service(5) — man7.org/linux/man-pages/man5/systemd.service.5 (service unit format)
• systemctl(1) — man7.org/linux/man-pages/man1/systemctl.1 (control the systemd manager)
• journalctl(1) — man7.org/linux/man-pages/man1/journalctl.1 (query the journal)
• systemd.timer(5) — man7.org/linux/man-pages/man5/systemd.timer.5 (timer units)
• freedesktop.org systemd docs — freedesktop.org/wiki/Software/systemd (official project documentation)