$linuxjunkies
>

How to Manage Services with systemctl

Learn to start, stop, enable, disable, and mask Linux services using systemctl, plus how to read failures and diagnose problems with journalctl.

BeginnerUbuntuDebianFedoraArch7 min readUpdated June 7, 2026

Before you start

  • A Linux system using systemd as its init system (all major distros since ~2015)
  • A non-root user account with sudo privileges
  • Basic familiarity with the terminal and running commands

systemd is the init system and service manager on virtually every major Linux distribution. Its primary user-facing tool is systemctl, which lets you start, stop, restart, enable, disable, mask, and inspect services. Once you understand the handful of core subcommands covered here, you can manage almost any service on any modern Linux machine.

Core Concepts in 30 Seconds

systemd organizes things into units. A service unit (ending in .service) describes how to run a background process. Two orthogonal properties matter most:

  • Active state — is the service running right now? Controlled by start / stop.
  • Enable state — does the service start automatically at boot? Controlled by enable / disable.

These are independent. A service can be enabled but currently stopped, or running right now but not set to start on boot.

Checking Service Status

Always check status first. It shows the active state, the enable state, the PID, memory use, and the last few log lines.

sudo systemctl status nginx

Realistic output looks like:

● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-04-15 09:12:44 UTC; 2h 4min ago
    Process: 1234 ExecStartPre=/usr/sbin/nginx -t
   Main PID: 1238 (nginx)
      Tasks: 3
     Memory: 6.1M
        CPU: 201ms
     CGroup: /system.slice/nginx.service
             ├─1238 "nginx: master process"
             └─1239 "nginx: worker process"

The Loaded line tells you the unit file path and whether it is enabled. The Active line is the runtime state. Output will vary; this is illustrative.

To list all loaded service units and their states at a glance:

systemctl list-units --type=service

Add --all to include inactive units, or --state=failed to see only failed ones.

Starting and Stopping Services

Start a service immediately

sudo systemctl start nginx

Stop a running service

sudo systemctl stop nginx

Restart vs. reload

restart stops then starts the process — there is a brief interruption. reload sends a signal asking the process to re-read its configuration without dropping connections (only works if the service supports it).

sudo systemctl restart nginx
sudo systemctl reload nginx

When you are unsure whether reload is supported, use reload-or-restart. systemd will try reload first and fall back to restart:

sudo systemctl reload-or-restart nginx

Enabling and Disabling Services at Boot

Enable a service to start on boot

sudo systemctl enable nginx

This creates a symlink in the appropriate wants or requires directory. It does not start the service right now.

Enable and start in one command

sudo systemctl enable --now nginx

Disable a service from starting at boot

sudo systemctl disable nginx

Disabling removes the symlink but does not stop a currently running instance. Use disable --now to also stop it immediately.

sudo systemctl disable --now nginx

Masking Services

Disabling a service prevents automatic startup but still allows a user or another unit to start it manually. Masking goes further: it symlinks the unit file to /dev/null, making it completely unstartable until unmasked. Use this for services you never want running, such as a conflicting network manager or a legacy service replaced by something else.

sudo systemctl mask NetworkManager-wait-online.service

Attempting to start a masked unit returns an error immediately. To reverse it:

sudo systemctl unmask NetworkManager-wait-online.service

Do not mask services casually. Masking systemd-networkd or similar fundamental units can leave a system unbootable.

Reading Failures and Diagnosing Problems

Identify failed units

systemctl list-units --state=failed

Get detailed status

When a service fails, systemctl status shows the last few journal lines inline. That is often enough to spot a misconfiguration or missing file.

sudo systemctl status myapp.service

Read the full journal for a service

For the complete log history, use journalctl with the -u flag:

sudo journalctl -u nginx.service

Add -e to jump to the end, or -f to follow in real time (like tail -f). To see only logs since the last boot:

sudo journalctl -u nginx.service -b

Check the unit file itself

If a service refuses to start, inspect what systemd is actually trying to run:

systemctl cat nginx.service

This prints the merged unit file including any drop-in overrides from /etc/systemd/system/nginx.service.d/.

After editing unit files

If you manually edit a unit file under /etc/systemd/system/, reload the daemon before your changes take effect:

sudo systemctl daemon-reload

Verifying Your Changes

After any change, confirm both the active state and the enable state match your intent:

systemctl is-active nginx
systemctl is-enabled nginx

Each command prints a single word (active, inactive, failed, enabled, disabled, masked, etc.) and sets a corresponding exit code — useful in scripts:

if systemctl is-active --quiet nginx; then
  echo "nginx is running"
fi

Quick Reference Table

GoalCommand
Check statussystemctl status <unit>
Start nowsystemctl start <unit>
Stop nowsystemctl stop <unit>
Restartsystemctl restart <unit>
Reload configsystemctl reload-or-restart <unit>
Enable at bootsystemctl enable --now <unit>
Disable at bootsystemctl disable --now <unit>
Prevent any startsystemctl mask <unit>
View full logsjournalctl -u <unit> -b
Reload unit filessystemctl daemon-reload

Troubleshooting Common Issues

  • "Unit not found" — The service name may include .service explicitly, or the package is not installed. Run systemctl list-unit-files | grep <name> to search.
  • Service starts then immediately exits — Check journalctl -u <unit> -b --no-pager for the actual error. Common causes: missing config file, wrong permissions, or a port already in use.
  • Changes not taking effect — You likely edited a unit file without running systemctl daemon-reload.
  • Service re-enables itself — Some packages use a systemd preset or a package manager hook. Check systemctl get-default and the unit's [Install] section with systemctl cat.
  • Masked unit blocks another service — Use systemctl unmask and then trace dependencies with systemctl list-dependencies <unit>.
tested on:Ubuntu 24.04Debian 12Fedora 41Arch rolling

Frequently asked questions

What is the difference between disabling and masking a service?
Disabling removes the boot-time symlink so the service won't start automatically, but it can still be started manually or by another unit. Masking symlinks the unit file to /dev/null, making it impossible to start by any means until unmasked.
Do I need to run daemon-reload after every change?
Only when you edit unit files on disk (in /etc/systemd/system/ or /lib/systemd/system/). Operations like start, stop, enable, or disable do not require it.
Why is my service enabled but not running after a reboot?
The service may be failing on startup. Check 'systemctl status <service>' and 'journalctl -u <service> -b' immediately after boot to see the error. A failed dependency or missing file is the most common cause.
Can I manage user-level services without sudo?
Yes. systemd supports per-user service managers. Use 'systemctl --user start <service>' without sudo to manage services defined in ~/.config/systemd/user/.
What does 'active (exited)' mean in the status output?
It means the service's ExecStart process ran and exited with a success code, which is expected for oneshot-type units that perform a task and finish rather than running as a persistent daemon.

Related guides