Controlling systemd Services and Writing Unit Files

systemd is the init system and service manager used by most modern Linux distributions. It is responsible for starting, stopping, and managing system services, as well as handling boot sequences and system state.

The primary tool for interacting with systemd is systemctl. With it you can:

• Start and stop services
• Enable or disable services at boot
• Inspect service status and logs
• Reload configuration without restarting

All services managed by systemd are defined by unit files, which are declarative configuration files stored under /etc/systemd/system/ (system-wide) or ~/.config/systemd/user/ (per-user).

These are the most commonly used systemctl commands for day-to-day service management. Each command operates on a unit name such as nginx.service or simply nginx.

• systemctl start <unit> — start a service immediately
• systemctl stop <unit> — stop a running service
• systemctl restart <unit> — stop then start (full restart)
• systemctl reload <unit> — send SIGHUP to reload config without stopping
• systemctl enable <unit> — create symlinks so the unit starts at boot
• systemctl disable <unit> — remove those symlinks
• systemctl status <unit> — show state, PID, recent log lines

systemctl status gives a rich snapshot of a unit. Understanding its output is essential for diagnosing problems quickly.

• Loaded: path to the unit file and whether it is enabled at boot
• Active: current state — active (running), inactive (dead), failed
• Main PID: the process identifier of the service's main process
• CGroup: all child processes belonging to the service
• Log lines: the most recent journal entries for this unit

You can also query just the active state with systemctl is-active and the enabled state with systemctl is-enabled, which are ideal for use in scripts.

When managing many services, you need ways to list and filter units efficiently. systemctl list-units shows all currently loaded units, while list-unit-files shows all installed unit files and their enabled state.

Useful filtering options:

• --type=service — show only service units
• --state=failed — show only failed units
• --state=active — show only active units
• --all — include inactive units in the listing

Combining these filters with grep lets you build powerful inspection pipelines in maintenance scripts.

A service unit file is a plain text INI-style file composed of sections. Each section controls a different aspect of the unit's lifecycle.

• [Unit] — metadata: description, ordering dependencies (After=, Requires=, Wants=)
• [Service] — how to start/stop the process: ExecStart, ExecStop, Restart, User, WorkingDirectory
• [Install] — when this unit should be enabled: WantedBy=multi-user.target means it activates during normal multi-user boot

After placing or editing a unit file under /etc/systemd/system/, you must run systemctl daemon-reload so systemd picks up the changes.

Let's create a simple service unit file for a custom Python HTTP server script. The unit file tells systemd exactly how to manage this process as if it were any other system service.

Key [Service] directives used here:

• Type=simple — systemd treats the ExecStart process as the main process
• User=www-data — run under a non-root account for security
• WorkingDirectory — set the process's working directory
• Restart=on-failure — automatically restart if the process exits with a non-zero code
• RestartSec=5 — wait 5 seconds between restart attempts

The Type= directive in [Service] tells systemd how to track when a service has finished starting. Choosing the wrong type is a common source of ordering bugs.

• Type=simple — default; systemd considers the service started as soon as ExecStart launches. No readiness signal needed.
• Type=forking — the ExecStart process forks and exits; the real daemon runs as a child. Use PIDFile= so systemd can track it.
• Type=notify — the process sends sd_notify(READY=1) when truly ready. Most reliable for complex daemons.
• Type=oneshot — runs once and exits; subsequent units wait for completion. Ideal for setup scripts.
• Type=idle — like simple but execution is delayed until all active jobs finish.

Service unit files support several directives for passing environment variables and applying security restrictions — both are important in production systems.

Environment directives:

• Environment="KEY=value" — set a single variable inline
• EnvironmentFile=/etc/myapp/env — load variables from a file (one KEY=value per line)

Common security hardening directives:

• NoNewPrivileges=true — prevent the process from gaining additional privileges via setuid
• ProtectSystem=strict — mount /usr, /boot, /etc read-only
• PrivateTmp=true — give the service its own isolated /tmp
• CapabilityBoundingSet= — drop all Linux capabilities

A systemd timer is a unit that activates another unit (usually a .service) on a schedule. It replaces traditional cron jobs with a more integrated, loggable, and controllable mechanism.

Every timer unit (foo.timer) is paired with a service unit of the same base name (foo.service) that does the actual work. You enable and start the timer, not the service directly.

Timer types:

• Realtime (calendar) timers — fire at wall-clock times using OnCalendar= expressions like daily, weekly, or Mon *-*-* 02:00:00
• Monotonic timers — fire relative to a system event using OnBootSec=, OnActiveSec=, or OnUnitActiveSec=

Let's build a complete timer + service pair that runs a backup script every day at 02:00. Notice how the [Timer] section lives in its own .timer file while the work lives in the paired .service file.

Key [Timer] directives:

• OnCalendar= — calendar expression for the schedule
• Persistent=true — if the system was off when the timer should have fired, run immediately on next boot
• RandomizedDelaySec= — add up to N seconds of random jitter to prevent thundering-herd when many hosts share the same schedule
• Unit= — explicit target unit (optional if names match)

systemd routes all service output to the journal, which you query with journalctl. This centralises logs from all units in one searchable store.

Essential journalctl flags for service troubleshooting:

• -u <unit> — filter by unit name
• -f — follow log in real time (like tail -f)
• -n 50 — show only the last 50 lines
• --since "1 hour ago" — limit by time
• -p err — show only error-priority and above
• -b — show logs from the current boot only

When a unit fails to start, the first thing to run is journalctl -u <unit> -n 30 --no-pager followed by systemctl status <unit> to capture the recent error context.

Test your understanding of systemd service and timer unit configuration.

In this lesson you explored the core concepts of systemd service management and unit file authoring at a professional level. Here is a summary of what was covered:

• systemctl basics — start, stop, restart, reload, enable, disable, status, is-active, is-enabled for scripting-friendly checks
• Listing and filtering — list-units and list-unit-files with --type and --state flags to isolate failed or enabled services
• Unit file anatomy — the three sections [Unit], [Service], and [Install] and their key directives
• Service types — simple, forking, notify, oneshot, and when to use each
• Environment and security — EnvironmentFile, NoNewPrivileges, ProtectSystem, PrivateTmp for hardened daemons
• Timer units — pairing .timer and .service files, OnCalendar expressions, and Persistent catch-up behaviour
• Journalctl — filtering by unit, time, boot, and priority to diagnose failures efficiently

With these skills you can manage any system service, schedule recurring tasks reliably, and author production-grade unit files for your own daemons.