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.
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
| Goal | Command |
|---|---|
| Check status | systemctl status <unit> |
| Start now | systemctl start <unit> |
| Stop now | systemctl stop <unit> |
| Restart | systemctl restart <unit> |
| Reload config | systemctl reload-or-restart <unit> |
| Enable at boot | systemctl enable --now <unit> |
| Disable at boot | systemctl disable --now <unit> |
| Prevent any start | systemctl mask <unit> |
| View full logs | journalctl -u <unit> -b |
| Reload unit files | systemctl daemon-reload |
Troubleshooting Common Issues
- "Unit not found" — The service name may include
.serviceexplicitly, or the package is not installed. Runsystemctl list-unit-files | grep <name>to search. - Service starts then immediately exits — Check
journalctl -u <unit> -b --no-pagerfor 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-defaultand the unit's[Install]section withsystemctl cat. - Masked unit blocks another service — Use
systemctl unmaskand then trace dependencies withsystemctl list-dependencies <unit>.
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
Back Up Linux with Borg or restic
Set up encrypted, deduplicated backups with BorgBackup or restic: local and remote repos, retention pruning, restoring files, and systemd timer scheduling.
How to Check Disk Health with SMART
Learn to use smartctl to read SMART attributes, run drive self-tests, and identify early warning signs of HDD and SSD failure before data loss occurs.
Debug systemd Units that Won't Start
Learn a repeatable workflow to debug systemd services that won't start: status output, journalctl, systemd-analyze verify, and safe override.conf patches.
Linux Server Disaster Recovery Checklist
A practical Linux server disaster recovery checklist: what to back up, RTO/RPO planning, immutable off-site copies, automated restore drills, and verification.