Linux Services: Systemctl Commands to Know Before a Random Reboot

Before restarting a Linux service, I always prefer to see what’s actually running. On a machine with systemd, systemctl It already provides almost everything you need: active services, failed services, automatic startup, detailed status and latest useful messages.

This is especially true on a server. Restart nginx, ssh, mariadb A business service, without checking its status, can terminate a session, interrupt a website, or mask a configuration error. Here are the commands you need to know to properly list Linux services, filter what matters, and then decide if a reboot is truly necessary.

List active services with systemctl

The most direct command is to display the currently loaded service-type units:

systemctl list-units --type=service

You get a list with several columns. The most important ones are LOAD, ACTIVE, SUB And DESCRIPTIONIn practice, I mainly look at ACTIVE And SUB : a service can be loaded, but stopped, in error, or simply terminated because that is its normal behavior.

To only see services that are currently running:

systemctl list-units --type=service --state=running

To display the services that are suspended:

systemctl list-units --type=service --state=exited

Don’t panic if you see services in exitedSome processes initiate a brief action and then stop normally. It’s necessary to examine the service in question before concluding that there’s a problem.

View failed services

When a machine malfunctions, start with this command:

systemctl --failed

It displays the units that systemd considers to be failing. This is more useful than a blind reboot, because you immediately see the exact name of the service to inspect.

Example :

systemctl status ssh

or, according to the distribution:

systemctl status sshd

The output shows the service status, the unit file being used, the primary PID if the service is running, and the last few log lines. If you need to diagnose a failed startup, these few lines often provide the first clue.

Determining if a service starts automatically

A service can be active now without being activated at startup. The reverse is also possible: a service can be activated, but stopped because it failed or because it has not yet been started.

To list the unit files and their state at startup:

systemctl list-unit-files --type=service

The most common states are:

enabled : the service is designed to start automatically;
disabled : it does not start automatically;
static : it is not activated directly, but can be called by another unit;
masked : the service is intentionally blocked.

To check a specific service:

systemctl is-enabled nginx
systemctl is-active nginx

The first command responds regarding automatic startup. The second responds regarding the current state. Neither piece of information replaces a… systemctl status, but they are handy in a control script or a quick checklist.

Filter the list without getting lost in it

On a somewhat busy server, the complete list quickly becomes long. You can filter with grep when you are looking for a family of services:

systemctl list-units --type=service | grep ssh

To display only active services without pager:

systemctl list-units --type=service --state=running --no-pager

And if you want a more readable output in a ticket or a short diagnosis:

systemctl list-units --type=service --state=failed --no-pager

On a remote server, I often add --no-pagerThis prevents you from getting stuck in the interactive display, especially when you’re working quickly via SSH.

Read the logs before restarting

If a service is experiencing an error, do not start by restartFirst, look at the newspapers:

journalctl -u nginx -n 50 --no-pager

To follow the live logs:

journalctl -u nginx -f

This is often where you’ll see an error like a port already in use, an invalid configuration file, an incorrect permission, or a missing dependency. If you’re new to systemd logs, I’ve also provided details. How to read the logs of the last Linux boot using journalctl.

Restart only after the checks have been completed.

Once the service is identified, check its configuration when the tool allows it. For Nginx, for example:

nginx -t

For SSH, be even more careful. If you restart the wrong service or if the configuration is invalid, you can lose remote access. Keep a session open, check the firewall, and then use SSH instead. reload when that’s enough.

sudo systemctl reload ssh
sudo systemctl restart ssh

The order reload requests the service to reread its configuration without stopping it completely, if the service supports it. restart The service is cut off and then restarted. This is not the same level of risk.

If you have modified a systemd unit file, also consider the difference with daemon-reloadI explained this case separately in the article. Systemctl daemon-reload: when should it really be used under Linux?.

The mini checklist before touching a service

List the relevant services with systemctl list-units --type=service.
Check for errors with systemctl --failed.
Read the precise status with systemctl status service-name.
Look at the logs with journalctl -u service-name.
Test the configuration if the service offers a validation command.
Prefer reload has restart when it is tolerated and sufficient.

The documentation of systemctl It details all the options, but for everyday use, these commands already cover most diagnostics. My advice: if you don’t know why you’re restarting a service, don’t restart it yet. List the issues, read the logs, and then take action.