systemctl list services: Every Way to List Linux Services

The one command to know: systemctl list-units --type=service

On any distribution that runs systemd — Ubuntu since 15.04, Debian since 8, RHEL and CentOS since 7, plus Fedora, Arch, and openSUSE — every service is a systemd unit, and systemctl is the tool that lists them:

systemctl list-units --type=service

By default this prints every service unit systemd currently has in memory: services that are active, that have queued jobs, or that failed. It does not show services that are installed but were never started. When the output is taller than your terminal, systemctl pipes it into a pager (less) — press q to quit, or add --no-pager to print straight to stdout.

Each line has five columns:

• UNIT — the unit name, for example ssh.service. This is the exact name you pass to systemctl status, start, and stop.
• LOAD — whether the unit file was parsed correctly: loaded, not-found, bad-setting, error, or masked.
• ACTIVE — the high-level state: active, inactive, activating, deactivating, or failed.
• SUB — the low-level state, specific to the unit type: a service can be running, exited, dead, and so on.
• DESCRIPTION — the human-readable text from the unit file.

Read the ACTIVE/SUB pair together: active (running) means a process is alive right now, while active (exited) means a oneshot service ran successfully and finished — normal for setup tasks, not a problem to fix.

Filtering: running, failed, or everything

The --state= flag filters on any LOAD, ACTIVE, or SUB value and accepts comma-separated lists:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed is a built-in shorthand for the failed filter and is worth running as a reflex on any box you log into. For machine-readable output, --no-legend drops the header and summary lines and --plain drops the bullet characters, so the columns stay stable for awk or cut. To search by name, pipe through grep: systemctl list-units --type=service --all --no-pager | grep ssh.

What starts at boot: systemctl list-unit-files

list-units answers "what is running now?". To answer "what will start at boot?", list the unit files installed on disk instead:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Here the STATE column describes the boot configuration, not the runtime state:

• enabled — starts automatically at boot (or on its trigger, for socket/timer-activated services).
• disabled — installed, but nothing starts it automatically.
• static — has no [Install] section; it only runs as a dependency of another unit and cannot be enabled directly.
• masked — symlinked to /dev/null; systemd refuses to start it at all.
• generated — created at runtime by a generator, typically from a legacy init script.

Recent systemd releases also print a preset column (VENDOR PRESET or PRESET depending on the version) showing what the distribution's default would be. The trap to avoid: enabled does not mean running, and disabled does not mean stopped. A service can be disabled yet running because someone started it by hand, or enabled yet dead because it crashed. When it matters, cross-check both listings.

One service at a time: status, is-active, is-enabled

Once a service catches your eye, zoom in:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status shows the full picture: ACTIVE/SUB state, main PID, uptime, memory usage, the cgroup process tree, and the last ten journal lines. When ten lines are not enough, go to the journal directly with journalctl -xeu nginx (-u filters by unit, -e jumps to the end, -x adds explanatory text).

The is-* commands are built for scripting: they print a single word and set the exit code accordingly — is-active exits 0 only when the unit is active, and is-enabled exits non-zero for disabled or masked units. Add --quiet to suppress the output and keep only the exit code.

All of the listing commands above work as an unprivileged user. Actually managing services — start, stop, enable, disable — requires root, so you will want to understand how sudo and user switching work on Ubuntu before you go beyond reading state. Note also that user-level units live in a separate manager: systemctl --user list-units --type=service lists services running in your own session, which is why some services seem "missing" from the system listing.

Cheat sheet: the listings you will actually use

Real-world workflows

1. Find the service that keeps failing

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Start wide with --failed, then read the status output for the exit code and the last log lines, then dig into the journal for the full trace. Once the root cause is fixed and the service is back up, reset-failed clears the stale failed entry so your next health check starts clean.

2. Audit what will start on next boot

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

The first command gives you a clean list of everything that will auto-start — useful before hardening a server or hunting down something you installed months ago and forgot. systemd-analyze blame then shows how long each unit took during the last boot, which is where slow-starting services stand out immediately.

3. One-liners for scripts and monitoring

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p prints Key=Value pairs that never change format between versions, and the JSON output feeds straight into jq. If you find yourself rerunning the same checks on every login, wrap them in a small script — our guide to .sh files and shell scripting covers turning exactly this kind of snippet into a reusable tool.

No systemd? service --status-all and OpenRC

Before assuming systemctl exists, confirm what the machine actually runs — checking the OS and version from the command line takes ten seconds and tells you whether you are on a systemd distribution at all. If systemctl is missing, you are on SysV init or OpenRC:

service --status-all

On Debian and Ubuntu this walks /etc/init.d and prints [ + ] for running, [ - ] for stopped, and [ ? ] for scripts with no status command. It still works on systemd distributions through a compatibility layer, but it only sees init scripts, so prefer systemctl there. On Alpine and Gentoo, OpenRC is the init system: rc-status lists services in the current runlevel and rc-update show lists what each runlevel starts.

Everything above assumes you have a Linux machine where you hold root and can start, break, and fix services freely. If you need one to practice on — or a clean box to host real workloads — a Linux VPS with full root access from rdp.monster comes with dedicated CPU and RAM, unlimited (fair-use) bandwidth, no KYC, and is delivered about 10 seconds after payment confirms, so you can be running systemctl list-units on your own server within the minute.

Frequently Asked Questions

Why does a service show active (exited) instead of active (running)?

It is a oneshot service that ran successfully and finished — not an error.

Services with Type=oneshot (or RemainAfterExit=yes) run a task once — mounting, firewall setup, cleanup — and exit. systemd then reports active (exited): the unit succeeded and is considered "on", but no process stays behind. Only daemons like nginx or sshd show active (running). If a service you expect to be a daemon shows exited, check its unit file with systemctl cat name.service to see how it is declared.

What do the colored dots in systemctl output mean?

Green means active, white means inactive, and red means failed or in error.

The bullet before a unit name in systemctl status and systemctl list-units is a quick state indicator: green for active, white for inactive or deactivating, and red for failed or error states. Failed rows are also highlighted in red in listings, which makes systemctl --failed easy to scan. In scripts or logs where color codes get in the way, add --plain or pipe the output, and the decorations disappear.

Is there a systemctl equivalent of chkconfig --list?

Yes — systemctl list-unit-files --type=service replaces chkconfig --list.

On RHEL and CentOS 7 or newer, chkconfig --list is replaced by systemctl list-unit-files --type=service, which shows every installed service and whether it is enabled, disabled, static, or masked. For a single service, systemctl is-enabled name replaces chkconfig name, and systemctl enable name replaces chkconfig name on. The old command may still exist as a compatibility shim, but it only covers legacy SysV scripts.

How do I stop a service from starting at boot?

Use systemctl disable to remove it from boot, or mask to block it entirely.

Run sudo systemctl disable name to remove the boot symlink; add --now to also stop it immediately. A disabled service can still be started manually or pulled in as a dependency of another unit. If you want it never to start at all, use sudo systemctl mask name, which links the unit to /dev/null so every start attempt fails. Reverse it later with systemctl unmask. Verify the result with systemctl is-enabled name.