Linux service list file

10+ commands to list all systemctl services with status

In this tutorial I will share the commands which you can use to list systemctl services along with their state. You can use these methods in scripts to add service status checks to make sure service is in running or failed state.

Are you new to systemd and systemctl?

With RHEL/CentOS 7, now we have services based on systemd and the SysV scripts are deprecated. If you are new to systemd then I would suggest reading this another article where I have done 1:1 comparison between SysV and systemd services.

Now with systemd the traditional Linux commands such as chckconfig , service etc are not supported any more. Although you can still use these commands but they can be removed in upcoming releases.

For example, with RHEL/CentOS 6 we used to use chkconfig to enable or disable service at different run level. Now with RHEL 8 also I see we are allowed to use chkconfig

# chkconfig postfix on Note: Forwarding request to 'systemctl enable postfix.service'. Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service.

But the request is internally routed to systemctl . Similarly you can restart a service using traditional command i.e. service . For example, to restart sshd :

# service sshd restart Redirecting to /bin/systemctl restart sshd.service

This request was also transferred to systemctl .

So I hope you understood the point, at the time of writing this article with RHEL 8.1

# cat /etc/redhat-release Red Hat Enterprise Linux release 8.1 (Ootpa)

we are still allowed to use traditional SysV commands but it can be removed in any release now. So I would strongly recommend users to start using systemctl commands as they are very user friendly and powerful tool with the amount of options they support.

With systemd we have unit files which are further classified into service , socket , target etc. So you must be very clear on your requirement if you wish to list only services, or sockets or any other type of unit.

systemctl list unit files loaded in memory

List active unit files

First of all we will list all the unit files which are currently available in the memory of our Linux server. This command will list only the active units from the server’s memory:

List all the unit files

To list all the units independent of their state add » —all » to this command

As you can see now it is loading all the unit files including failed , inactive unit files

systemctl list installed unit files

Now list-units shows the list of units which are currently loaded in the memory but not necessarily installed on the server. To view the list of unit files which are currently installed on our server we use:

Here this command will show all the installed unit files independent of their state unlike list-units which shows only the active unit files. Adding —all with this command will have no advantage.

List type of unit files

There can be different types of unit files such as service, socket, mount etc. To further filter the unit files we can add type= argument with list-unit-files . The argument should be a comma-separated list of unit types.

systemctl list services

To list all the installed systemctl services from our Linux server:

# systemctl list-unit-files --type=service

This should give us a complete list of installed services (independent of it’s state)

systemctl list mount files

With systemd all the partitions and file system are mounted as part of mount type unit files. So we can also list all the mount type unit files available on our server using type=mount

# systemctl list-units --all --type=mount

We can further use this with different other type of unit files such as socket, target etc.

List state of services

To check if a service is enabled/disabled/static/indirect, you must use list-unit-files with systemctl while to check if a service is running/active/failed/dead etc then you must use systemctl list-units . To get complete list of supported options with list-units and —state , use systemctl —state=help

systemctl list enabled services

To list all the service unit files which are currently in enabled state use —state=enabled

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

systemctl list disabled services

We can provided multiple state type with —state= argument where individual state values will be comma separated. For example to list all the systemctl service which are either enabled or disabled

# systemctl list-unit-files --type=service --state=enabled,disabled

systemctl list running services

To list the running services we will use list-units in combination with —type=service and —state=running

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

systemctl list failed services

To list failed services you can use —state=failed

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

OR alternatively we can directly use

Check service status of individual unit file

Now the above commands will give you the status of all the unit files which are installed or available on your server. To check the status of individual file we do not want to use those commands in combination with grep and other filter utility.

Now assuming I wish to check the status of sshd service. So I can use

which can give me a long list of output along with the actual status such as active, running loaded. Now these three states can also be grepped individually using the properties of a unit file

To check if a systemctl service is running or not use:

# systemctl show sshd --property=SubState SubState=running

To check if a service is active or inactive :

# systemctl show sshd --property=ActiveState ActiveState=active

# systemctl is-active sshd active

To check if a service is loaded or not:

# systemctl show sshd --property=LoadState LoadState=loaded

So we can individually grep the state of individual services using their properties. To list all the properties of a service you can use:

Conclusion

In this article we learned little bit more about systemd and systemctl unit files. I have explained about the different types of unit files and commands using which we can get the list of running services, sockets, targets etc with systemctl . We can also get individual status of services using the property of unit files which gives us much more control over the details of each service. We can use these properties in scripts for automation purpose.

Lastly I hope the steps from the article to list running services on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

References

I have used below external references for this tutorial guide

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

Источник

How to list service with systemd

If someone asks you to show the whole configuration of your system, use the dump command.

The file covers all units you have on the system. Once a developer has this file available, the person will go through what you have and try to find the problems you are facing. Over and done. However, you would not be reading this article if you were going to let someone else do everything. Let us see what you can do with a service at a time and learn some tricks to filter your results.

The hierarchy of systemd

To become efficient you need to realise that, within systemd, you have hierarchy and you can set each service to depend and/or wait for other services. The different ways you do this is evident in the service files. The different statements you have are ‘Wants’, ‘Required’, ‘Before’ and ‘After’. For effective analysis, you can use these to see if your unit is down because of dependancies. You can then trace back to where the underlying problem lies. Here is an exmample of this.

The printout shows the other units that xpra.service rely on. In this case the other units are active, so wee need to focus on why the unit itself is broken. The example was missing a certificate file.

The most important use of this is to investigate if your service is missing dependencies, use the command this way.

The result is a long list, conveniently organised in a tree and showing all services as green or red if something is wrong. You can also see the dependencies in the services file. Open the file using your favourite editor or use systemctl, which will open the file with the default editor.

Listing active services

When you want to investigate a system, you will need to know how the units fit together. To do this, you have a number of options for printing the details. You can list which systems are busy, failed and so on. More importantly you can list how they are put together, which unit, service etc. the current unit depends on. The main command to do this is systemctl, the options are useful to narrow in on your specific issue.

To get the proper use of systemctl, look carefully at the options for the command. There are options to choose exactly what you need, especially regarding the state of any services. Here we are looking for services that have problems.

This list is also long and you have to scroll through all the services to find what you are looking for. With some more parameters, you can filter for a specific one or the ones that are disabled. The below command will find all units that are masked.

Masked services are blocked so that other services cannot start them, even if the other service needs them. This can be used for securing that you do not have conflicting services running. Commonly, many services are masked by your package manager when you remove the package. You can remove the service file completely if you wish after removing a service. It is also possible that it wrecks a lot of services that you do want so make sure you know if you need the masked services.

Some services are masked by processes and you do not always intend for the service to be masked. When this has happened to your system, the first action to take is to unmask using systemctl. However, this is not always possible so you need to take away the link in the proper directory. In most systems, this will be lib/systemd/system. Before you do though, check that the file is actually a link to /dev/null.

When you are certain that you want to remove this link, remove it with rm or unlink.

Now that you know how to do it, hear this warning: many times it is necessary to have this link in there. Take lvm2 as an example, it is masked from operation so it will not interfere with the new system, where lvm2 comes as many small services. See the result of:

Removing the link may cause havoc on your system because lvm2 itself needs it off to avoid conflicts. This is only an example, so watch out before you move on.

Conclusion

When you want to list services in systemd, you must first reflect on what you are looking for in your quest. Are you looking for a service you need or do you see that you have too many services. Either way, you need to adapt your query to your particular needs. Systemd looks confusing at first but when you look closer, it all uses a straightforward way to unify start-up so services can start in parallel where the system needs it while being able to have every service wait for the specific service they depend on.

About the author

Mats Tage Axelsson

I am a freelance writer for Linux magazines. I enjoy finding out what is possible under Linux and how we can all chip in to improve it. I also cover renewable energy and the new way the grid operates. You can find more of my writing on my blog.

Источник