Manage systemd services with systemctl is one of the most essential skills for any Linux system administrator or DevOps engineer in 2025–2026. Since systemd became the default init system on virtually all major distributions (Ubuntu, Debian, Fedora, CentOS Stream, Rocky Linux, AlmaLinux, and more), the systemctl command is now the central tool for controlling services, checking statuses, modifying boot behaviour, and troubleshooting.
This comprehensive 2025–2026 guide teaches you exactly how to manage systemd services with systemctl — from starting and stopping units, enabling/disabling autostart, reloading configurations, masking dangerous services, viewing dependencies, and interpreting status output, to handling common errors and best practices.
Key Takeaways – How to Manage Systemd Services with systemctl
- Manage systemd services with systemctl using the primary command systemctl for starting, stopping, restarting, enabling, disabling, and checking systemd services and units.
- Use start, stop, restart, reload, and reload-or-restart to control running services when you Manage systemd services with systemctl.
- Enable and disable manage autostart behaviour at boot — critical for production services while learning how to manage systemd services with systemctl.
- Status, is-active, is-enabled, and is-failed give instant health insights — essential commands when you manage systemd services with systemctl.
- list-units, list-unit-files, and list-dependencies help explore the current system state as part of how to manage systemd services with systemctl.
- Masking (mask/unmask) completely prevents a service from starting — a powerful security feature when you manage systemd services with systemctl.
- Override unit files safely using systemctl edit — never modify /lib/systemd/system/ directly while managing systemd services with systemctl.
- Targets replace traditional runlevels — use isolate, rescue, emergency, reboot, etc., to control system states when you manage systemd services with systemctl.
Prerequisites
- Any modern Linux distro using systemd (Ubuntu 20.04+, Debian 10+, Fedora 35+, Rocky/AlmaLinux 8/9, etc.)
- Terminal access with sudo privileges
- Basic familiarity with Linux services and commands
Why Learn How to Manage Systemd Services with systemctl?
Before systemd, Linux used SysVinit, Upstart, or other init systems — each with different tools and syntax. Today, managing systemd services with systemctl is the universal standard across most distributions, making your skills portable and future-proof. Mastering systemctl lets you:
- Control services without guessing
- Debug startup failures quickly
- Secure systems by disabling/masking risky units
- Customise boot behaviour with targets
- Automate reliably in scripts and Ansible playbooks
Basic Service Control – Start, Stop, Restart, Reload
All commands below assume you’re operating on a service unit (e.g., nginx.service). The .service suffix is optional — systemctl assumes it for service-related commands.
Start a Service
sudo systemctl start nginx.service
# or shorter:
sudo systemctl start nginx
Stop a Service
sudo systemctl stop nginx.service
Restart a Service (stop → start)
sudo systemctl restart nginx.service
Reload Configuration (without stopping)
Many services (nginx, apache, postfix, etc.) support reload:
sudo systemctl reload nginx.service
If unsure whether reload is supported:
sudo systemctl reload-or-restart nginx.service
This reloads if possible, restarts otherwise.
Enable & Disable Services at Boot
Enable Autostart
sudo systemctl enable nginx.service
Creates symbolic links in /etc/systemd/system/multi-user.target.wants/ (or similar target).
Disable Autostart
sudo systemctl disable nginx.service
Removes the symlink — service won’t start on boot.
Note: enable/disable do not start/stop the service in the current session — use start/stop separately.
Checking Status & Health
Full Status Report
sudo systemctl status nginx.service
Shows:
- Loaded state (enabled/disabled/masked)
- Active state (active/inactive/failed)
- Main PID
- Recent logs
- CGroup processes
Example output snippet:
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2025-07-01 10:15:23 UTC; 2h ago
Main PID: 1234 (nginx)
Tasks: 5 (limit: 4915)
Memory: 18.2M
CPU: 1.234s
CGroup: /system.slice/nginx.service
├─1234 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─1235 nginx: worker process
Quick State Checks
systemctl is-active nginx.service # → "active" or "inactive"
systemctl is-enabled nginx.service # → "enabled", "disabled", "masked"
systemctl is-failed nginx.service # → "active" or "failed"
Exit code 0 = yes/true, non-zero = no/false — perfect for scripts.
Listing & Exploring Units
All Active Units
systemctl list-units
# or just services:
systemctl list-units --type=service
All Units (including inactive/failed)
systemctl list-units --all
All Unit Files (loaded or not)
systemctl list-unit-files
# Filter:
systemctl list-unit-files --type=service
Show Dependencies Tree
systemctl list-dependencies nginx.service
Advanced – Masking Units (Ultimate Disable)
Masking links a unit to /dev/null — completely prevents start (even manually).
sudo systemctl mask nginx.service
Unmask:
sudo systemctl unmask nginx.service
Editing & Overriding Unit Files Safely
Never edit files in /lib/systemd/system/ — upgrades will overwrite them.
Create Override Snippet
sudo systemctl edit nginx.service
Opens editor with blank override file — add changes here, e.g.:
[Service]
Restart=always
RestartSec=5s
Saved to /etc/systemd/system/nginx.service.d/override.conf
Edit Full Unit File
sudo systemctl edit --full nginx.service
Saves copy to /etc/systemd/system/nginx.service
After any edit:
sudo systemctl daemon-reload
sudo systemctl restart nginx.service
System State & Targets (Modern Runlevels)
Targets group units into system states.
Common targets:
- multi-user.target — command-line multi-user mode
- graphical.target — GUI desktop
- rescue.target — single-user rescue mode
- emergency.target — minimal emergency shell
Check default:
systemctl get-default
Change default:
sudo systemctl set-default multi-user.target
Switch immediately:
sudo systemctl isolate multi-user.target
Quick actions:
sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl rescue
sudo systemctl emergency
Common Errors & Fixes When Managing Systemd Services with systemctl
- Unit not found → Typo in name, or .service needed? Use systemctl list-unit-files | grep nginx
- Failed to start → Check logs: journalctl -u nginx.service -xe
- Permission denied → Forgot sudo — most systemctl actions require root.
- Changes not applied → Forgot daemon-reload after editing units.
- Service masked → systemctl unmask first.
- Dependency failed → systemctl list-dependencies and fix broken units.
Manage Systemd Services with systemctl – FAQ (2025–2026)
- How do I manage systemd services with systemctl to start one?
sudo systemctl start nginx.service — basic way to manage systemd services with systemctl. - How do I restart a service when managing systemd services with systemctl?
sudo systemctl restart nginx.service — stops and starts in one step. - How do I make a service start on boot when managing systemd services with systemctl?
sudo systemctl enable nginx.service — creates boot symlinks. - How do I check why a service failed when managing systemd services with systemctl?
sudo systemctl status nginx.service and journalctl -u nginx.service -xe. - What does reload do when managing systemd services with systemctl?
sudo systemctl reload nginx.service — reloads config without stopping. - How do I completely block a service when managing systemd services with systemctl?
sudo systemctl mask nginx.service — strongest disable method.
Summary
You now know exactly how to manage systemd services with systemctl — start/stop/restart/reload, enable/disable at boot, check status, explore units, override configs, mask units, switch targets, and troubleshoot errors. These skills are universal across modern Linux servers in 2025–2026.
Practice on a non-production system first — then apply to real workloads (nginx, apache, docker, mariadb, redis, etc.).
Recommended Resources
- Official systemd Documentation (freedesktop.org)
- journalctl – View systemd Logs
- Understanding systemd Units and Targets
- Linux Service Management Cheat Sheet
