Check and manage running services on Linux with systemctl

Understand systemd and service units

systemd is the init system and service manager used by Ubuntu, Debian, AlmaLinux, Rocky Linux and Fedora. It starts services at boot, restarts them if they crash, and tracks their state through unit files.

Unit files for services usually end in .service and live in /etc/systemd/system/ or /usr/lib/systemd/system/. You interact with all of them through the systemctl command, regardless of which distro you use.

Check the status of a service

The systemctl status command is the first thing to run when you want to know whether a service is active, when it started, and what it has logged recently.

systemctl status ssh

On AlmaLinux, Rocky Linux and Fedora the SSH service is usually named sshd instead of ssh.

systemctl status ssh

systemctl status sshd

The output shows the load state, the active state (active/running, inactive/dead, or failed), the main process ID, memory usage, and the last few log lines. A green dot means the service is currently running.

Check if a service is active or enabled with short checks

If you just need a quick yes/no answer rather than the full status output, use is-active and is-enabled. These are useful in scripts because they return clean exit codes.

systemctl is-active nginx
systemctl is-enabled nginx

These commands print active/inactive/failed and enabled/disabled respectively, without the extra detail from status.

Start, stop and restart a service

Use start to bring a stopped service up, stop to shut it down cleanly, and restart to stop and start it in one step. Restart is what you want after changing a config file.

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

If a service supports it, reload applies configuration changes without dropping active connections, which is safer than a full restart for something like a busy web server.

sudo systemctl reload nginx

Enable or disable a service at boot

Starting a service manually only lasts until the next reboot. To make a service start automatically every time the server boots, enable it.

sudo systemctl enable nginx

To start the service immediately and also enable it at boot in one command, use the combined flag.

sudo systemctl enable --now nginx

To prevent a service from starting at boot, disable it. This does not stop a currently running instance, so stop it separately if needed.

sudo systemctl disable nginx
sudo systemctl disable --now nginx

List all services on the system

To see every loaded service unit and its current state, list unit files filtered by type.

systemctl list-units --type=service --all

To see only services that are currently running, drop the --all flag.

systemctl list-units --type=service

To check which services are set to start on boot versus which are disabled, list the unit files themselves rather than their runtime state.

systemctl list-unit-files --type=service

Find failed services

When something has crashed or failed to start, systemd marks it as failed. This is the fastest way to spot problems across the whole system after a reboot or deployment.

systemctl --failed

If this list is not empty, investigate each entry with systemctl status and journalctl before moving on. A failed service will not retry on its own unless it has a restart policy configured in its unit file.

Read service logs with journalctl

systemd centralizes logs in the journal, and journalctl is how you read them. This is essential for figuring out why a service failed to start.

sudo journalctl -u nginx

To follow logs live as new entries arrive, similar to tail -f, add the -f flag.

sudo journalctl -u nginx -f

To see only logs since the last boot, which is useful when a service failed right after a restart, combine the unit filter with the boot flag.

sudo journalctl -u nginx -b

To limit output to recent entries, use --since with a relative or absolute time.

sudo journalctl -u nginx --since "1 hour ago"

If you manage disk space used by the journal, see optimize systemd journal logging performance and storage for retention and size limits.

Inspect a unit file and reload systemd after changes

If you edit a unit file directly, for example to add environment variables or change the restart policy, systemd will not pick up the change until you reload its configuration cache.

sudo systemctl cat nginx

[Service]
Restart=on-failure
RestartSec=5s

sudo systemctl daemon-reload
sudo systemctl restart nginx

Use systemctl edit nginx instead of editing the vendor unit file directly. It creates an override file in /etc/systemd/system/ that survives package upgrades.