How to List Services with systemctl

Need to see what services are running on your Linux server? The quick answer:

systemctl list-units --type=service

That shows every service systemd currently has loaded and active. Add --all to include services that are loaded but inactive or failed:

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

Below is what each variant does, how to filter the output, and the related commands you will reach for right after listing services.

Running services only

The default list-units view already hides inactive units, but you can be explicit about wanting only services that are actively running:

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

The columns mean:

• UNIT: the service name, for example nginx.service
• LOAD: whether systemd successfully read the unit file
• ACTIVE and SUB: the high level and low level state, such as active (running)
• DESCRIPTION: the human readable name from the unit file

list-units vs list-unit-files

These two commands answer different questions and mixing them up is the most common source of confusion.

list-units shows the current state: what is running or failed right now. list-unit-files shows the startup configuration: what is set to start at boot.

systemctl list-unit-files --type=service

The STATE column here says enabled (starts at boot), disabled (installed but does not start automatically), static (only started as a dependency of something else), or masked (blocked from starting at all).

So "is nginx running" is a list-units question, while "will nginx start after a reboot" is a list-unit-files question.

Finding failed services

After a reboot or an incident, the first thing worth checking:

systemctl --failed

This lists every unit in a failed state. From there, check the log of a specific failure:

journalctl -u nginx.service --since "1 hour ago"

Checking a single service

When you care about one service rather than the whole list:

systemctl status nginx

This prints the state, the main process ID, memory usage, and the last few log lines in one view. For scripting, use the quieter variants:

systemctl is-active nginx
systemctl is-enabled nginx

Both print a single word and set an exit code, which makes them ideal inside shell scripts and health checks.

Cleaner output for scripts

The default output pipes through a pager and adds a legend. For machine friendly output, disable both:

systemctl list-units --type=service --no-pager --no-legend

You can then process the result with awk or grep as usual, for example counting running services:

systemctl list-units --type=service --state=running --no-pager --no-legend | wc -l

Managing what you found

Listing is usually a step toward starting, stopping, or changing boot behavior:

sudo systemctl start nginx      # start now
sudo systemctl stop nginx       # stop now
sudo systemctl restart nginx    # stop then start
sudo systemctl reload nginx     # reload config without dropping connections
sudo systemctl enable nginx     # start at every boot
sudo systemctl disable nginx    # do not start at boot
sudo systemctl enable --now nginx  # enable and start in one command

Common errors

• Unit nginx.service could not be found: the package is not installed, or the service has a different name. Search installed unit files with systemctl list-unit-files | grep -i nginx.
• Permission denied or authentication prompts: state changing commands need root. Prefix with sudo; plain listing commands work as any user.
• Using the old service command: service nginx status still works on most distributions but is only a compatibility wrapper. The systemctl forms above are the native interface on any modern systemd distribution.

Beyond services: other unit types

Services are only one kind of systemd unit. The same listing syntax works for the others, which is handy when a "service" turns out to be socket activated or timer driven:

systemctl list-units --type=socket
systemctl list-units --type=timer
systemctl list-timers

list-timers is the systemd equivalent of reading a crontab: it shows each timer, when it last ran, and when it fires next. If a service seems to start "by itself", a socket or timer unit with the same name is usually the reason, and listing those two types will reveal it.

To see how services relate to each other, print the dependency tree for a unit:

systemctl list-dependencies nginx.service

Related commands

• journalctl -u <service>: logs for one service
• systemctl daemon-reload: re-read unit files after editing them
• systemd-analyze blame: which units slowed down the last boot

All of the above works the same on any systemd based distribution (Ubuntu, Debian, Rocky, Alma, Fedora and others), whether it is a laptop or a Linux VPS you manage over SSH.