systemctl Essentials: Start, Stop, Enable, and Inspect Units

systemctl is the primary interface for managing systemd units. Once you know a small set of verbs and how to inspect state, you can handle most service operations quickly and safely.

Table of Contents

This post covers the command patterns you will use most on real systems.

Lifecycle Management

Inspection and Analysis

Series Navigation

Manage service lifecycle

Most day-to-day work starts with service lifecycle actions.

sudo systemctl start nginx.service
sudo systemctl stop nginx.service
sudo systemctl restart nginx.service
sudo systemctl reload nginx.service
sudo systemctl try-restart nginx.service

Choose verbs deliberately:

  • Use restart when you need a full process restart
  • Use reload when the service supports config reload without downtime
  • Use try-restart when you only want to restart services that are already running

Enable and disable at boot

Service runtime state and boot-time enablement are separate concerns. A running service is not automatically enabled for the next boot unless a unit install link exists.

sudo systemctl enable nginx.service
sudo systemctl disable nginx.service
sudo systemctl enable --now nginx.service
sudo systemctl disable --now nginx.service
systemctl is-enabled nginx.service
systemctl is-active nginx.service

enable --now is a strong default for first-time deployment because it activates the unit immediately and persists it for reboot.

Mask and unmask for hard blocks

Masking links a unit to /dev/null, which blocks all start attempts including dependency-driven starts.

sudo systemctl mask bluetooth.service
sudo systemctl unmask bluetooth.service

Use masking when you need to guarantee a unit cannot be started accidentally.

Inspect unit state

Start with status, then move deeper with show when you need machine-readable properties.

systemctl status nginx.service
systemctl show nginx.service -p ActiveState -p SubState -p UnitFileState -p FragmentPath
systemctl cat nginx.service

Helpful interpretations:

  • ActiveState tells high-level state like active or failed
  • SubState gives finer detail such as running, exited, or dead
  • FragmentPath shows where the base unit file is loaded from
  • systemctl cat includes active drop-ins merged for that unit

Filter unit views

You can quickly narrow unit listings by type and state.

systemctl list-units --type=service --state=running
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

This is useful during incident response when you need a focused list of failed or inactive components.

Reloading unit metadata

Whenever you create or change unit files, systemd needs to reload metadata before new definitions are visible.

sudo systemctl daemon-reload

daemon-reload does not restart running services by itself, so follow with explicit restart or reload where required.

Boot performance analysis

systemd includes built-in boot timing tools for baseline and troubleshooting work.

systemd-analyze
systemd-analyze blame | head -20
systemd-analyze critical-chain

These commands help identify slow units and dependency chains that delay readiness.

Safe operating habits

A few habits reduce surprises in production:

  • Never edit vendor units directly in /usr/lib/systemd/system
  • Prefer drop-ins under /etc/systemd/system/<unit>.d/
  • Check status and logs after restarts before closing a change
  • Use explicit unit names when scripts may target similarly named services

Series navigation

Now that command usage is clear, the next step is understanding service unit internals and why specific directives change behavior.

Next in this series

Next, we break down the anatomy of service unit files so you can read, override, and author unit behavior with confidence.

systemd Service Units: Anatomy of a Unit File