systemctl Essentials: Start, Stop, Enable, and Actually Understand Services

Every modern Linux distribution boots into systemd, and systemd in turn supervises nearly every long-running process on the machine. That makes systemctl the single most important command in your server toolkit. Yet two distinctions trip up almost everyone who picks it up casually: the difference between starting and enabling a service, and what the various states in systemctl status actually mean. Clear those up and the rest of systemd becomes approachable.

Start, Stop, Restart: Controlling Runtime State

Starting a service asks systemd to spawn it now. Stopping asks it to terminate. These verbs are immediate and non-persistent: they change what is running on this boot and say nothing about future boots.

systemctl start nginx           # start now, silent on success
systemctl status nginx          # state plus recent log lines
systemctl restart nginx         # full stop, then start
systemctl reload nginx          # re-read config without dropping connections
systemctl stop nginx            # terminate

Two nuances matter. First, systemctl is quiet on success, so script against systemctl is-active when you need a yes-or-no answer instead of parsing colored output. Second, restart and reload are not interchangeable. restart runs the unit's full stop-then-start sequence and works for every unit; reload only fires ExecReload, which the unit author must have defined. If ExecReload is missing, reload fails with an error rather than quietly falling back to a restart. Reload is for daemons like nginx and sshd that can re-read configuration in place; use restart for everything else.

Enable Is About Boot, Start Is About Now

The most common systemctl misunderstanding is treating enable as a synonym for start. It is not. enable does not touch the running system at all. It creates a symlink in a .wants directory so the unit gets pulled in on future boots.

systemctl enable nginx          # start on every future boot
systemctl is-enabled nginx      # enabled
systemctl disable nginx         # stop starting at boot

systemctl enable --now nginx    # enable AND start in one step
systemctl disable --now nginx   # disable AND stop

Four combinations are worth memorizing: started and enabled, started but disabled (running until the next reboot), stopped but enabled (it will return on reboot), and stopped and disabled. When a colleague says a service was running yesterday but vanished after a reboot, they almost always had the second combination. Package-managed services on Debian, Ubuntu, and RHEL-family systems are usually enabled and started at install time; units you write yourself stay dormant until you enable them explicitly.

Reading status Output Like a Diagnostic Tool

systemctl status is not just a green or red light. It packs five distinct pieces of diagnostic data into one screen, and reading them in order turns it into a first-response tool.

• Loaded shows which unit file systemd is using and whether it is enabled, disabled, or masked.
• Active reports the state and sub-state: active (running) for daemons, active (exited) for oneshot units that finished their job, failed when the last start attempt died.
• Main PID identifies the exact process systemd considers the service itself, which matters when the unit spawns children.
• The cgroup section lists every process currently inside the service, so a runaway helper script shows up immediately.
• The trailing journal lines show the most recent log entries for this unit without a separate command.

systemctl status nginx --no-pager -l
systemctl is-active nginx
systemctl is-failed nginx
systemctl show nginx -p MainPID -p ActiveState -p SubState

The show command is the scripting-friendly version of status: one property per line, no colors, no truncation. Build health checks on it rather than on screen-scraping the pretty output.

Listing What Is Actually on the Machine

Two listing commands answer different questions. list-units shows what systemd currently has loaded and running; list-unit-files shows everything installed, whether or not it is loaded.

systemctl list-units --type=service --state=running
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service
systemctl cat nginx             # the unit file as systemd sees it

systemctl cat deserves a habit of its own: run it before editing any unit file. It prints the real path systemd loaded plus any drop-in overrides stacked on top, which is exactly the information you need before changing anything. A later post in this series covers those drop-ins in depth.

The takeaway: start and stop manage the present, enable and disable manage the future, and status is five clues rather than one color. Keep those axes separated in your head and most systemctl confusion evaporates on contact.

Want a clean Ubuntu 24.04 VPS to practice on? Netbay deploys one in under 60 seconds — netbayhosts.in.