How To List All Services In Linux : Systemd Service Unit Files

by

If you’re managing a Linux system, knowing how to list all services in Linux is essential for troubleshooting, performance tuning, and security audits. The command systemctl list-units --type=service shows all active services on your Linux machine, but there are several other commands to examine service states, including those for older init systems like SysVinit. This guide covers every method, from basic to advanced, so you can always find exactly what’s running.

Services are background processes that start at boot or on demand. They handle tasks like web servers, databases, and logging. Understanding how to list them gives you control over system resources and helps you spot problems quickly.

How To List All Services In Linux

Before we jump into commands, let’s clarify what “service” means in Linux. A service is a daemon—a program that runs in the background without direct user interaction. Modern Linux distributions use systemd, but some still rely on SysVinit or Upstart. The commands differ slightly, so we’ll cover all major scenarios.

The most common way to list services is with systemctl. This tool is part of systemd, which is the default init system for Ubuntu (since 15.04), Fedora, CentOS 7+, Debian (since 8), and most modern distros.

Using Systemctl To List Services

Open your terminal and type:

systemctl list-units --type=service

This shows all loaded service units. You’ll see columns like UNIT, LOAD, ACTIVE, SUB, and DESCRIPTION. The ACTIVE column tells you if the service is running, exited, or failed. The SUB column gives more detail, like “running” or “dead”.

To see all services, including inactive ones that are still installed, use:

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

This includes services that are disabled or not currently loaded. It’s useful for auditing what’s available on your system.

For a simpler list of only service names, pipe the output:

systemctl list-units --type=service --all | grep -E '\.service' | awk '{print $1}'

That extracts just the unit names. You can also use systemctl list-unit-files --type=service to see all service unit files, regardless of their current state. This shows whether each service is enabled or disabled at boot.

Checking Service Status With Systemctl

Once you have a list, you might want details on a specific service. Use:

systemctl status service-name.service

For example, systemctl status sshd.service shows if SSH is running, its PID, memory usage, and recent log entries. This is faster than grepping log files.

To see only active services (running or exited), omit the --all flag. To see only failed services, use:

systemctl --failed --type=service

That’s a quick way to find broken services after a reboot or update.

Listing Services With Service Command

On older systems using SysVinit, the service command works. It’s also available on systemd systems for compatibility. To list all services, type:

service --status-all

This shows every service in /etc/init.d with a status indicator: [ + ] for running, [ - ] for stopped, [ ? ] for unknown. The output is simple but doesn’t show detailed info like systemctl does.

Note that service --status-all only lists services managed by SysVinit scripts, not systemd units. On hybrid systems, you’ll see a mix.

Using Init Scripts Directly

For pure SysVinit systems, you can list scripts in /etc/init.d:

ls /etc/init.d/

This shows all available init scripts. To check their status, run each script with the status argument:

/etc/init.d/scriptname status

But that’s tedious for many services. Use service --status-all instead for a bulk view.

Listing Services With Ps And Grep

If you prefer a low-level approach, you can list running processes that are likely services. Use:

ps aux | grep -E 'systemd|sshd|nginx|apache|mysql'

This is not a definitive list of services, but it shows active daemons. Combine it with systemctl for accuracy. For a cleaner view, use:

ps -eo pid,comm,args | grep -v grep | grep -E 'systemd|sshd|httpd'

You can also use top or htop to see running processes interactively, but they don’t separate services from user processes.

Listing Services With Netstat Or Ss

Network services listening on ports are often critical. Use ss (modern) or netstat (older) to list them:

ss -tulpn

This shows TCP and UDP ports with the process name and PID. For example, you’ll see sshd on port 22, nginx on 80/443. Combine with systemctl to confirm the service unit.

If netstat is installed, use:

netstat -tulpn

Both commands require root to see all processes. Without root, you’ll only see your own processes.

Listing Services With Lsof

The lsof command lists open files, including network sockets. To find services listening on ports:

sudo lsof -i -P -n | grep LISTEN

This shows the process name, PID, and port. It’s useful for identifying which service owns a specific port.

Listing Services With Systemd Analyze

For a boot-time perspective, use:

systemd-analyze blame

This lists all services and how long they took to start during the last boot. It helps identify slow services. Another variant:

systemd-analyze critical-chain

Shows the dependency chain and which services are delaying boot.

Listing Services With Chkconfig (Rhel/Centos)

On older Red Hat-based systems, chkconfig manages runlevel services. To list all services and their runlevel status:

chkconfig --list

This shows which services are enabled for each runlevel (0-6). On modern systems, this command is deprecated in favor of systemctl.

Listing Services With Update-Rc.D (Debian/Ubuntu)

On Debian-based systems, update-rc.d manages SysVinit scripts. To see enabled services:

ls /etc/rc*.d/

This shows symbolic links for each runlevel. Services starting with ‘S’ are started, ‘K’ are killed. It’s a low-level view but works.

Listing Services With Journalctl

If you want to see service logs, use:

journalctl -u service-name.service

To list all services that have logged recently:

journalctl --list-boots | head -10

That shows boot IDs, then you can check services per boot. Not a direct list, but useful for debugging.

Listing Services With Docker Or Container Runtimes

If you run containers, services inside them are separate. On the host, list container services with:

docker ps

For systemd-nspawn containers, use machinectl list. Container services don’t appear in systemctl on the host.

Common Pitfalls And Tips

One mistake is confusing services with processes. Not all processes are services, and some services spawn multiple processes. Always use systemctl for authoritative service info.

Another pitfall: on systems with both systemd and SysVinit (like Ubuntu 14.04), commands may give incomplete results. Stick to systemctl if available.

If you get “Failed to get D-Bus connection”, you’re likely in a container or chroot without systemd running. Use service --status-all or check /etc/init.d instead.

For remote servers, use SSH and run these commands. Consider using watch to monitor services in real time:

watch -n 2 'systemctl list-units --type=service --state=running'

This updates every 2 seconds.

Automating Service Lists

You can save a list of services to a file for auditing:

systemctl list-units --type=service --all --no-legend > services.txt

Or create a script to compare service states between servers:

#!/bin/bash
systemctl list-units --type=service --all --no-legend | awk '{print $1}' | sort > /tmp/services1.txt
# On another server, do the same and diff
diff /tmp/services1.txt /tmp/services2.txt

This helps find discrepancies in configurations.

Security Implications

Listing services helps identify unnecessary daemons that could be attack vectors. Disable unused services with:

systemctl disable service-name.service

Then stop them:

systemctl stop service-name.service

Regular audits using the commands above reduce your attack surface.

Performance Monitoring

Services consume CPU and memory. Use systemctl status to see resource usage, or combine with ps:

ps -o pid,pcpu,pmem,comm -p $(systemctl show -p MainPID service-name.service | cut -d= -f2)

This shows CPU and memory for a specific service’s main process.

Debugging Failed Services

When a service fails, systemctl --failed lists it. Then check logs:

journalctl -u service-name.service --since "5 minutes ago"

Common failures include missing dependencies, permission issues, or configuration errors.

Cross-Distribution Differences

Ubuntu and Debian use systemd by default, but some older versions use Upstart. On Upstart, use initctl list to see jobs. Fedora and CentOS 7+ use systemd. Arch Linux also uses systemd. For Alpine Linux (which uses OpenRC), list services with rc-service --list.

Always check your distro’s init system before choosing a command.

Advanced: Listing Services With D-Bus

For programmatic access, use D-Bus commands:

busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager ListUnits

This returns raw data. It’s overkill for most users but useful for scripting.

Using Systemctl With Filters

You can filter by state:

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

Other states: exited, dead, failed, active, inactive. Combine multiple states with commas:

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

This shows only running and failed services, hiding inactive ones.

Listing Services By Dependency

To see which services depend on a specific service:

systemctl list-dependencies service-name.service

This shows a tree of required and wanted units. Useful for understanding boot order.

Using Grep For Custom Lists

If you only care about web servers, for example:

systemctl list-units --type=service --all | grep -iE 'http|nginx|apache'

This narrows down results. You can also use systemctl list-unit-files with grep.

Listing Services With Python Or Bash Scripts

For automation, use Python’s subprocess module:

import subprocess
result = subprocess.run(['systemctl', 'list-units', '--type=service', '--all', '--no-legend'], capture_output=True, text=True)
print(result.stdout)

Or a simple bash one-liner:

for s in $(systemctl list-units --type=service --all --no-legend | awk '{print $1}'); do echo "$s: $(systemctl is-active $s)"; done

This prints each service with its active state.

Understanding Service States

Services can be active (running), active (exited) (for oneshot services), inactive (dead), failed, or activating. The systemctl list-units output shows these clearly.

Enabled services start at boot. Disabled ones need manual start. Check enable status with:

systemctl is-enabled service-name.service

Or list all enabled services:

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

Common Service Examples

Here are typical services you’ll see:

  • sshd.service – SSH server
  • nginx.service – Nginx web server
  • apache2.service – Apache web server
  • mysql.service – MySQL database
  • postgresql.service – PostgreSQL database
  • cron.service – Cron scheduler
  • rsyslog.service – System logging
  • NetworkManager.service – Network management
  • ufw.service – Uncomplicated Firewall
  • docker.service – Docker container runtime

Each distro may name them slightly differently (e.g., httpd.service on RHEL vs apache2.service on Ubuntu).

When To Use Each Method

  • Quick overview: systemctl list-units --type=service
  • All installed services: systemctl list-unit-files --type=service
  • Failed services: systemctl --failed
  • SysVinit systems: service --status-all
  • Network services: ss -tulpn
  • Boot performance: systemd-analyze blame
  • Container environments: Check inside the container

Final Tips

Always run these commands with appropriate privileges. Some info requires root. Use sudo when needed. Remember that services can be masked (prevented from starting) – check with systemctl list-unit-files.

If you’re new to Linux, start with systemctl list-units --type=service. It’s the most reliable and widely supported. As you gain experience, explore