How to Use systemctl - Linux Service Management Guide

2025-12-16 Reading time: About 8 min Difficulty: Intermediate+

What you'll be able to do

Read a service state from systemctl status output
Choose safely between start, stop, restart, and reload
Set auto-start correctly by telling enable apart from start

Prerequisites (read these first)

Process States and Lifecycle in Linux

What You'll Learn

You can read systemctl status output and tell whether a service is running.
You can choose between start, stop, restart, and reload knowing what each one changes.
You can set auto-start as intended because you know how enable differs from start.

Quick Summary

Master these commands and you'll handle most situations:

Check status: systemctl status <service>
Start: systemctl start <service>
Stop: systemctl stop <service>
Restart: systemctl restart <service>
Reload config: systemctl reload <service> (if supported)
Enable auto-start: systemctl enable <service>
Disable auto-start: systemctl disable <service>

On Ubuntu, most commands require admin privileges, so add sudo. sudo means "run this one command as the administrator".

Prerequisites

OS: Ubuntu
systemd environment
Permissions: sudo access

1. What is systemctl?

Conclusion: systemctl is systemd's service manager for start, stop, restart, and status.

systemctl is the systemd service management command. You can start/stop/restart/check status of services running on the server (e.g., nginx, apache2, ssh, docker).

Four terms to settle first.

Term	One-line meaning	Note
systemd	The component that boots Linux and manages its services	Also called the "init system"
daemon	A program that keeps running in the background with no UI	Also called a "resident process"
service	The name systemd uses for a daemon it manages	This article uses "service" throughout
unit	The general term for anything systemd manages	A service is one kind of unit, named like `nginx.service`

"Daemon", "service", and "unit" get mixed together in practice. Everything systemctl acts on is a unit. A service is a kind of unit, so nginx and nginx.service mean the same thing.

2. Start with "status"

Conclusion: Always begin troubleshooting with systemctl status to read active or failed.

Troubleshooting always starts here. status only reads state. It never starts or stops anything, so you can run it as often as you like.

$ sudo systemctl status nginx

● 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 Mon 2025-12-15 10:12:03 UTC; 2h 5min ago
   Main PID: 1234 (nginx)
      Tasks: 3 (limit: 4610)
     Memory: 5.6M
     CGroup: /system.slice/nginx.service
             ├─1234 nginx: master process /usr/sbin/nginx -g daemon on;
             └─1235 nginx: worker process

Key indicators:

Active: active (running) → Running
Active: inactive (dead) → Stopped
Active: failed → Failed (needs investigation)
enabled / disabled inside Loaded: loaded (...; enabled; ...) → the auto-start setting (see §5)

Active: is the state right now; the enabled in the Loaded: line is the setting for the next boot. The two are independent, so read both from a single status call.

For failed status, check logs with journalctl -u - that's the fastest path.

3. start/stop/restart

Conclusion: Use start, stop, restart to control a service; restart after config changes.

These commands change the state of the server. Check what changes and how to undo it before you run them.

Command	What it changes	How to undo	Safer way to try it
`start`	A stopped service begins running	`stop` stops it again	Record current state with `status` first
`stop`	The service goes down immediately (a web site becomes unreachable)	`start` brings it back	Do it when no one is using the service
`restart`	Brief downtime, then the service comes back up	Revert the config and `restart`	Run the config syntax check first

3-1. Start

$ sudo systemctl start nginx

3-2. Stop

$ sudo systemctl stop nginx

stop takes effect the instant you run it. On a production server, confirm who depends on the service before stopping it. If you stopped it by mistake, sudo systemctl start <service> brings it back.

3-3. Restart

$ sudo systemctl restart nginx

After config changes, use restart. If the service supports reload, you can use reload to apply changes without downtime.

4. reload / reload-or-restart

Conclusion: reload applies config without downtime; reload-or-restart is the safe fallback.

reload re-reads the configuration file without stopping the service. Not every service supports it.

4-1. reload (only for supported services)

$ sudo systemctl reload nginx

4-2. reload-or-restart (safe fallback)

$ sudo systemctl reload-or-restart nginx

Uses reload if supported
Falls back to restart otherwise

4-3. reload and daemon-reload Are Different

The names look alike, and this is the pair people mix up most. What each one re-reads is completely different.

Command	What it re-reads	When to use it
`systemctl reload <service>`	The service's own config (`nginx.conf`, …)	After editing a config file
`systemctl daemon-reload`	systemd's unit files (`*.service`)	After editing a unit file

If you edited a unit file (under /etc/systemd/system/, for example) and restart alone changes nothing, this is why.

$ sudo systemctl daemon-reload
$ sudo systemctl restart nginx

daemon-reload only makes systemd re-read the definitions; it does not restart the service. You still need restart to apply them.

5. Auto-start (enable/disable) - Common Beginner Issue

Conclusion: enable sets auto-start on next boot; you still need start to run it right now.

"It's running now, but stops after reboot" - this is the problem.

enable and disable only change whether the service comes up on the next boot. They do not touch the service that is running right now.

5-1. Enable auto-start

$ sudo systemctl enable nginx

5-2. Disable auto-start

$ sudo systemctl disable nginx

Forgetting that you ran disable turns the next reboot into an outage. To undo it, run sudo systemctl enable <service>. systemctl is-enabled <service> reads the current setting without changing anything.

5-3. Check auto-start status

$ systemctl is-enabled nginx

enabled

What the output means:

enabled: Auto-start ON
disabled: Auto-start OFF

6. Troubleshooting "not working"

Conclusion: Check status, read logs with journalctl, verify config syntax, then restart.

6-1. Check status

$ sudo systemctl status nginx

6-2. If failed, check logs (fastest path)

$ sudo journalctl -u nginx -n 200

journalctl reads the logs systemd collected. -u limits output to one unit, and -n 200 limits it to the last 200 lines.

Real-time tracking:

$ sudo journalctl -u nginx -f

6-3. Check config syntax first (e.g., nginx)

$ sudo nginx -t

nginx -t only reads the config file; it does not change how the service runs.

If you restart with broken config, the service may stay down. Check syntax first → restart if OK is the safe approach.

7. Finding Service Names

Conclusion: Service names vary, so grep systemctl list-units --type=service to find them.

Service names vary by environment (e.g., Apache is apache2 on Ubuntu).

Search from list:

$ systemctl list-units --type=service | grep -i apache

List all (many results):

$ systemctl list-units --type=service

list-units only prints a list. It leaves service states untouched.

8. Common Pitfalls

Conclusion: Running yet unreachable means check ports or firewall; enable alone won't start.

8-1. status shows "running" but can't access

Even if the service is running, port binding, firewall, or application errors can prevent access. A firewall allows or blocks traffic; on Ubuntu it is usually ufw. Combine with "port connectivity (ss/lsof/nc/curl)" troubleshooting for faster resolution.

8-2. Enabled but not running

enable means "auto-start on next boot". To start now, you also need start.

$ sudo systemctl enable nginx
$ sudo systemctl start nginx

9. Completion Checklist

Conclusion: After any change, verify state, auto-start setting, and logs before you finish.

[ ] systemctl status <service> reports active (running)
[ ] systemctl is-enabled <service> shows the value you intended (enabled / disabled)
[ ] journalctl -u <service> -n 50 shows no new errors
[ ] If you stopped or restarted it, users can reach the service again

Summary (Copy-Paste Template)

# Check status
sudo systemctl status <service>

# Start/Stop/Restart
sudo systemctl start <service>
sudo systemctl stop <service>
sudo systemctl restart <service>

# Reload config (if supported)
sudo systemctl reload <service>
sudo systemctl reload-or-restart <service>

# Auto-start
sudo systemctl enable <service>
sudo systemctl disable <service>
systemctl is-enabled <service>

# Logs
sudo journalctl -u <service> -n 200
sudo journalctl -u <service> -f