How to use systemctl for system services

systemctl is the command-line interface for systemd, the init system used by most modern Linux servers. Although older guides often use the service wrapper, systemctl exposes richer state, dependency, journal, and boot controls. Common choices in Australian fleets include RHEL, CentOS Stream, and Fedora.

Two service states need separate attention: whether a unit is running now and whether it starts automatically at boot. systemctl start changes the first state, while systemctl enable changes the second. Keeping these actions distinct prevents a service from being made persistent without a deliberate decision.

Administrators may support systems across Sydney, Melbourne, and Brisbane, including workloads in Australian public-cloud regions. Australian Eastern time governs scheduling, and daylight saving changes wall-clock times in Sydney and Melbourne. During an early-morning on-call handover, checking the live state is often more useful than relying on memory.

Service journals can contain customer identifiers, IP addresses, and operational details, so Australian teams must consider the Privacy Act 1988 (Cth) when deciding what to retain or share. A sound workflow combines routine service control with clear logging, limited privileges, and an easy recovery path.

Understand systemd units and dependencies

systemd represents each managed resource as a unit. A .service unit describes a daemon such as sshd.service or nginx.service, while targets group units for boot and dependency handling. Short names such as sshd are resolved automatically, so the .service suffix is optional.

Use systemctl list-units --type=service --state=running to view active services and systemctl --failed to isolate failures. For one unit, systemctl is-active nginx reports runtime state, whereas systemctl is-enabled nginx reports its boot policy.

Inspect status and journal logs

systemctl status nginx --no-pager shows the active state, main process ID, and recent journal entries without sending output through a pager. In scripts, systemctl is-active --quiet nginx provides a simple exit-status check; a non-zero result means the unit is not active.

For deeper investigation, use journalctl -u nginx -b --no-pager to read entries from the current boot. Add -n 100 for a short tail or --since "30 min ago" for a time window. The systemd journal is usually the best first source when a service starts but exits immediately.

Start, stop, and restart services

sudo systemctl start nginx, stop, and restart control the running process. A configuration-only change may suit reload, but that action fails unless the unit defines ExecReload=. reload-or-restart provides a fallback, while try-restart affects the unit only when it is already running.

Choose the least disruptive valid action. Reloading a healthy web server can avoid dropping connections, whereas a restart may be necessary after changes to a unit’s command line or environment. Afterwards, confirm systemctl is-active nginx and inspect fresh journal entries rather than assuming the command succeeded.

Control startup behaviour

sudo systemctl enable nginx creates boot-time links so the service starts automatically; it does not start the service immediately. sudo systemctl disable nginx removes those links but leaves a running process untouched. systemctl enable --now nginx combines enabling and starting for a newly installed unit.

Masking is stronger than disabling: systemctl mask nginx prevents accidental activation by linking the unit path to /dev/null. Use unmask before enabling it again. On packaged systems, systemctl preset nginx can apply the distribution’s default policy, which is useful after comparing vendor and local overrides.

Edit unit files safely

Inspect definitions with systemctl cat nginx or property values with systemctl show nginx. systemctl edit nginx creates a local drop-in under /etc/systemd/system, preserving the vendor file. This makes a small override easier to review and revert than editing the original unit directly.

After changing a unit, run sudo systemctl daemon-reload, then restart or reload the affected service; daemon-reload only refreshes systemd’s view of unit files. Validate syntax with systemd-analyze verify nginx.service. A workstation user who prefers a graphical editor can open the same files in Magik Emacs, although server changes should still follow local access controls.

Schedule recurring service work

Cron remains familiar to many Linux users, but systemd timers integrate cleanly with service dependencies, missed-run handling, and the journal. This guide to scheduled tasks with systemd explains the scheduling model and shows how timer units differ from ordinary service units.

A timer named backup.timer can trigger backup.service. Its calendar event might be OnCalendar=Mon..Fri *-*-* 07:00 Australia/Sydney, while Persistent=true catches a run missed because the machine was off. Enable and start the timer with sudo systemctl enable --now backup.timer, then inspect systemctl list-timers --all. Calendar schedules should be reviewed during daylight-saving transitions; Brisbane remains on standard time, whereas Sydney and Melbourne change clocks.

Build a reliable service runbook

Before a change, record systemctl show nginx -p ActiveState -p SubState -p FragmentPath, inspect systemctl cat nginx, and preserve the relevant drop-in. Check dependencies and available disk space as well. This evidence makes it easier to distinguish a pre-existing fault from a new configuration error.

Apply one controlled edit, reload systemd, use the appropriate restart or reload action, and verify both unit state and journal output. If the change fails, systemctl revert nginx removes local drop-in overrides so the previous configuration can be retested. The practical takeaway is to treat every unit change as a small deployment: inspect first, validate, apply, and confirm healthy logs.