How to List Linux Services With systemctl

Linux laptop with a bash prompt
fatmawati ahmad zaenuri/Shutterstock.com

To view all running services on a Linux system with systemd, use the “systemctl –type=service –state=running” command. This will show you the name, load, sub-state, and description of each active service. You can also change the status value to show services that are dead, stopped, down, or inactive.

Your Linux computer relies on many background tasks called services or daemons. On systemd-based distros you have built-in commands that you can use to see which services are running, disabled, or down.

services and demons

Services and daemons are background tasks that run without a user interface, require no human interaction, and typically start when the computer boots.

At one time services were started by init, that was the very first process that was started. The details of the services were stored in a collection of scripts located in the /etc/init/d directory. This is still the case with non-systemd distributions.

In the systemd world, services are started by systemd this is the first process that is now started. The details of the services are stored in unit files located in the /usr/lib/systemd directory.

According to its man page, systemd is system and service manager. You can use the… systemctl Command to inspect and control various aspects of the systemd system, including services and daemons.

Since we’re dealing with systemd-specific commands here, the first thing you need to know is whether you’re running a systemd-based distribution or not.

TIED TOGETHER: Why Linux is still splitting after all these years

init or systemd based?

The vast majority of Linux distributions use systemd, including Arch, Red Hat, and Debian, and many of the distributions derived from them. These include the Ubuntu family of distributions, Fedora and its spins, and Manjaro and the other Arch-based distributions.

However, there are forks or variants of some of these distributions that are specifically made to avoid using systemd. Not only that, but there are other init systems that someone could use instead of the one that comes standard with their distribution, such as: B. runit or s6-linux-init.

If you need to manage a Linux machine that you haven’t set up yourself, the only way to be sure if it’s using systemd or not is to check. We can do that by looking at the process tree with the pstree Command. We only need to see the top of the tree—after all, we’re looking for the very first process to run—so let’s pipe the output through the head command and ask for the first five entries.

pstree | head -5

Using pstree passed through head to determine if a Linux installation is using systemd

We can see that systemd is the first process to run after boot, so we’re definitely on a systemd-based installation of Linux.

TIED TOGETHER: How to manage processes from the Linux terminal: 10 commands you need to know

Using systemctl to list services

The command to list services and daemons is systemctl. We can refine them systemctl command with the type and state options. We ask systemctl to report on services that are in the running state.

systemctl --type=service --state=running

Using systemctl to list running services

An information table is generated. If it’s too wide or too long for your terminal window, it will show up in your default file viewer, which it probably will less.

The output of a systemctl call, shown in the Less file viewer

To view the right end of the table, press the right arrow key. To return to normal view, press the left arrow key.

The right portion of the output of a systemctl call, as viewed in the Less file viewer

Press the Q button to exit less. The columns shown are:

  • Unit: The name of the service or daemon. The column is titled “Unity” because everything in that column started with information systemd found in a unit file.
  • burden: The loading status of the service or daemon. It can be loaded, not found, set incorrectly, corrupted or masked.
  • active: The overall status that the service or daemon is in. It can be active, reload, inactive, failed, enable or disable.
  • SUB: The sub-state of the service or daemon. It can be dead, terminated, failed, inactive or active.
  • description: A brief description of the unit.

We can direct the output from systemctl through grep if we want to focus on a single service. This command isolates the table entry for the ssh Service.

systemctl --type=service --state=running | grep ssh

Using grep to isolate a single service from the results

So far we have filtered the contents of the table by providing the state=running Possibility. We can use any of the possible values ​​of the substate instead: “dead”, “exited”, “failed”, “inactive”, or “running”.

Let’s look for failed services:

systemctl --type=service --state=failed

Reporting failed services with systemctl

Combinations of substates can be used. Enter them as a comma-separated list. Make sure you don’t include spaces between options. Note that this finds matching services either Condition.

systemctl --type=service --state=failed,exited

Look for services that are either down or stopped with systemctl

If you press the right arrow key to look at the off-screen columns, we’ll see that we have a mix of stopped and failed services in the list.

A mix of failed and stopped services found by systemctl

By default, systemctl lists processes – services and daemons – started by systemd because systemd found a unit file that contained a valid unit file for it. Therefore, the short term for all these processes is “units”.

There is an option to request explicitly systemctl for listing units, but as this is the default action it is not used often.

These commands produce the same results.

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

Using systemctl to list unit files

We can expand the scope systemctl command by including the list-unit-files Possibility. This not only reports on started services and daemons, but also lists all of them unit files installed on your computer.

systemctl list-unit-files --state=enabled

List unit files with systemctl

A colored table is displayed.

A list of the unit files generated by systemctl, shown in the Less file browser

remove the state Option removes filtering. The output includes all installed unit files regardless of their status.

systemctl list-unit-files

Using systemctl to list unit files without filtering

The output contains many more entries than the results of the previous commands.

All unit files listed by systemctl and displayed in less file browser

On our test computer, the list of results is almost four times as long as the output of our previous commands.

If you want to use the state option, you can use multiple states with it, as we saw earlier. The same rules apply. Specify the options as comma-separated values ​​and do not include spaces.

This command lists all unit files that are either disabled or failed to start.

systemctl list-unit-files --state=enabled,failed

Using systemctl to search for unit files that match one of two states

A reduced number of results will be displayed, filtered by the selection you made with the status option.

A mix of disabled and failed unit files found by systemctl

Consider a service in detail

If something about a service or daemon catches your interest and deserves a deeper dive, you can use the systemctl status option to drill down into it.

Let’s take a look at the SSH daemon sshd. All we have to do is use the status option and the name of the service or daemon.

systemctl status sshd

The details of an individual service, displayed by systemctl

This compact display shows:

  • The name of the service along with a short description. A color-coded dot indicates whether it’s running or not. Green means it’s running, red means it’s not running.
  • What was loaded, including the path to the unit file.
  • how long it runs
  • Where is the documentation located in the man Manual.
  • The process ID of the running instance.
  • How many concurrent instances of this service are running. Usually this will be one.
  • How much memory is consumed.
  • How much CPU time was consumed.
  • The control group to which the service belongs.

Relevant entries from the system log are also displayed. These are typically events such as the start of the service. These can be informative if you are looking for a service or daemon that did not start correctly.

TIED TOGETHER: How to use journalctl to read Linux system logs

The autonomous systems

Services and daemons provide many of your operating system’s automatic actions, so they are critical. This means that their health is also crucial.

Getting an overview of your services, daemons, and unit files is easy and informative. It’s also a valuable troubleshooting step when a service or daemon refuses to start.

TIED TOGETHER: How to solve Too Many Open Files error on Linux

Leave a Reply

Your email address will not be published. Required fields are marked *