The dump command
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.
