If you’ve ever tried to start a web server, enable a database at boot, or troubleshoot why your SSH service won’t respond, you’ve probably encountered systemctl. It’s the command that controls almost everything running on a modern Linux system. And once you master how to use systemctl in Linux, you’ll wonder how you ever managed without it.
I remember my first real encounter with systemctl. I was migrating from an older CentOS box that still used the classic service command. Suddenly, none of my muscle memory worked. That frustration became a turning point – it forced me to actually understand what was happening under the hood.
This guide covers everything from basic commands to advanced troubleshooting techniques. Whether you’re just getting started or you want to sharpen your sysadmin skills, you’ll walk away with practical knowledge you can use today.
What is systemctl (And Why Every Linux Admin Needs It)
At its core, systemctl is the command-line interface for systemd – the init system that now powers most Linux distributions. Think of systemd as the conductor of an orchestra, and systemctl as your way of talking to that conductor.
Every time your Linux machine boots, systemd decides which services to start, in what order, and how to handle dependencies between them. When you run systemctl start nginx, you’re telling systemd to bring up your web server right now.
Get a VPS from as low as $11/year! WOW!
Understanding systemd vs Traditional Init Systems
Before systemd, Linux used traditional init systems like SysVinit and Upstart. These worked fine but had limitations. They started services one at a time in sequence, making boot times painfully slow on machines with many services.
Systemd changed the game by starting services in parallel. Fedora adopted it in 2011, followed by Arch Linux in 2012, then Debian and Ubuntu in 2014. Today, systemd v256 has reduced average startup times by 18.4% compared to earlier versions.
“Everybody who has ever worked at that level in the operating system has agreed that systemd is the proper solution. It solves a problem that people have. Distros have adopted it because it solves a problem for them.”
With Linux powering over 78% of web-facing servers in 2025, understanding systemctl isn’t optional anymore – it’s essential.
My First systemctl Crisis (And What It Taught Me)
Here’s a confession: I once locked myself out of a headless Proxmox server in my homelab. I had disabled sshd instead of stopping it, then rebooted. The difference? Disabling affects boot time. Stopping affects runtime. I had effectively told the system “never start SSH again.”
I spent an hour driving to my home office to plug in a keyboard and monitor. All because I confused two commands. That day, I learned the difference between enable and start the hard way.
Don’t be like past me. Let’s break down these commands properly.
Essential systemctl Commands Every Admin Should Know
These are the commands you’ll use daily. I recommend practicing on non-critical services first – maybe a development web server rather than production SSH.
Starting and Stopping Services
The most basic operations are starting and stopping services:
sudo systemctl start nginx
sudo systemctl stop nginxThese commands take effect immediately. When you start a service, it begins running right now. When you stop it, it terminates. Neither command affects what happens at boot time.
sudo with systemctl commands that modify service states. Without it, you’ll get a permission denied error.
Enabling and Disabling Services (The Boot Time vs Runtime Difference)
This is where most newcomers get confused. Enabling and disabling controls whether a service starts automatically at boot:
sudo systemctl enable nginx
sudo systemctl disable nginxHere’s the critical insight: enabling doesn’t start the service. And starting doesn’t enable it. These are completely separate operations.
- Enable: Create startup links so the service launches at boot
- Disable: Remove those startup links
- Start: Run the service right now
- Stop: Terminate the service right now
When I set up a new server, I typically need both: systemctl enable nginx (so it survives reboots) AND systemctl start nginx (so it runs now).
Checking Service Status
Before making changes, always check the current state. The status command shows you everything:
systemctl status nginxThis displays whether the service is active (running), enabled (starts at boot), its process ID, memory usage, and recent log entries. For a deeper dive into status output, check out my guide on how to check systemd service status.
I make it a habit to run status both before and after any changes. It takes two seconds and saves hours of troubleshooting.
Restarting vs Reloading Services
After modifying a configuration file, you need to apply those changes. You have two options:
sudo systemctl restart nginx
sudo systemctl reload nginxRestart completely stops and starts the service. All connections drop. Reload tells the service to re-read its configuration without terminating.
For SSH, this distinction matters. If you restart sshd, all active SSH sessions disconnect. If you reload it, existing connections stay alive while new connections use the updated config.
reload whenever the service supports it. Reserve restart for situations where a full reset is necessary.
Troubleshooting Failed Services with systemctl
Things break. Services fail to start. Configurations have typos. Dependencies go missing. The good news is systemctl gives you powerful tools to figure out what went wrong.
Finding Failed Units
When something breaks, start with this command:
systemctl --failedThis shows all units that failed to start or crashed. On a healthy system, this list should be empty. When it’s not, you know exactly which services need attention.
I run this command whenever a server behaves unexpectedly. It’s saved me countless hours of guessing.
Reading Service Logs with journalctl Integration
Once you’ve identified a failed service, dig into its logs:
journalctl -u nginxThis shows all log entries for that service. Add -f to follow logs in real-time, or -n 50 to see the last 50 lines. For a complete guide on log analysis, see my journalctl tutorial.
Common failure causes include:
- Dependency issues: A required service isn’t running
- Permission problems: The service can’t access files it needs
- Configuration errors: Syntax mistakes in config files
- Port conflicts: Another process is using the same port (use the lsof command to find what’s holding a port)
Resetting Failed Services
After fixing the underlying issue, clear the failed state:
sudo systemctl reset-failed nginxThis removes the “failed” marker so your --failed output stays clean. Then start the service normally.
Advanced systemctl Techniques
Once you’ve mastered the basics, these techniques will make you more efficient.
Using –now for Enable and Start
Remember how I said enabling and starting are separate? There’s a shortcut:
sudo systemctl enable --now nginxThe --now flag combines both operations. It enables the service for boot AND starts it immediately. This is my go-to when setting up new services.
The same works for disabling:
sudo systemctl disable --now nginxThis stops the service and prevents it from starting at boot – all in one command.
Masking vs Disabling Services
Disabling a service removes its startup links. But another process or admin could accidentally re-enable it. If you want a service to NEVER run – even if someone tries – use masking:
sudo systemctl mask nginx
sudo systemctl unmask nginxA masked service is linked to /dev/null. Any attempt to start it fails immediately. I use this for services that pose security risks if accidentally started, like the UFW firewall on systems using iptables directly.
The official systemd documentation covers masking in detail if you want the full technical reference.
Listing All Services and Units
To see every service on your system:
systemctl list-units --type=serviceThis shows running services. To see ALL services (running or not):
systemctl list-unit-files --type=serviceI use these commands when auditing a server. They reveal which services are enabled, disabled, or masked. Combined with the ps command, you get a complete picture of what’s running.
For the complete technical specification of all options, check the systemctl man page.
Common systemctl Mistakes to Avoid
I’ve made all of these mistakes. Learn from my pain.
- Confusing enable/disable with start/stop: They’re orthogonal. Enabling doesn’t start. Starting doesn’t enable. Repeat this until it becomes instinct.
- Not restarting after config changes: Editing nginx.conf does nothing until you reload or restart the service.
- Using restart when reload works: This drops active connections unnecessarily. Check if the service supports reload first.
- Forgetting sudo: Systemctl needs root privileges to modify service states. You’ll get cryptic errors without it.
- Not checking status: Always verify before and after changes. Assumptions cause outages.
- Disabling when you should mask: If a service should never run, mask it. Disabling leaves the door open for accidental restarts.
For scheduled maintenance and automating tasks with cron, combine cron jobs with systemctl commands carefully. Test your scripts manually before scheduling them.
Wrapping Up
Mastering systemctl transforms how you interact with Linux systems. Start with the basics – start, stop, enable, disable, status. Once those feel natural, add troubleshooting with --failed and journalctl. Then explore advanced features like masking and the --now flag.
The key insight? Enable and disable control boot behavior. Start and stop control runtime. Keep that distinction clear, and you’ll avoid 90% of systemctl headaches.
Practice on your development environment first. Spin up a test VM or use your homelab. Break things intentionally, then fix them. That hands-on experience builds the muscle memory you need when production systems need attention.
Ready to level up your Linux administration skills? Explore more of my guides on reading system logs with journalctl or learn about interpreting systemd service status for deeper troubleshooting.
