System V style init and systemd in practice

Systemd Fundamentals

Knowing a few rules can make working with systemd straightforward and successful. Here are some important things to remember:

• A unit must be enabled so that you can start it manually or automatically.
• A unit must be disabled so that it cannot be started again.
• A unit, or a non-modified unit file you created on your own, should be masked to protect it from inadvertently being enabled.
• You should move a unit which has a service file in /etc/systemd/system up one directory level. This ensures the file against inadvertently being enabled.
• A masked unit can only be re-enabled if it is unmasked beforehand. There is no unit file in /etc/systemd/system .
• You should copy or move a file that you have created or modified to /etc/systemd/system .

When masking a unit, a link pointing to /dev/null will be saved in the target directory. This indicates to systemd that the unit file with this designation should not be considered. A concrete example is provided in the following section.

Administration with systemctl

Now that you have become acquainted with the systemctl program for controlling systemd, the most important options are listed in Table 7.

It is possible to fine-tune many options with additional entries. It is not possible, however, to list all of these within the confines of this article. The following examples provide a lot of information for everyday use.

Figure 5 is a complete example of how to terminate and mask a service, PostgreSQL-RDBMS, and then how these measures are reversed.

Figure 5: Working with systemctl.

The unit file is not in /etc/systemd/system . You will find all of the processes belonging to the service for the status request systemctl status …. . Additionally, the status itself and its lifetime is indicated. You can receive a listing of all unit files with systemctl list-unit-files (Figure 6).

Figure 6: List of all unit files.

Alongside the states discussed previously (enabled , disabled and masked ), you will also find the state static . In this state, the unit file is not enabled, but it has no pertinent instructions in its [Install] section. Therefore, it cannot be controlled by systemctl for a variety of reasons: The particular unit might be referenced by other units, such as .wants , .requires . Another reason could be that the unit should be activated via a socket, timer, D-Bus, or udev.

It is possible to refine your state requests by including more conditions, for example --state . Frequently, it is easier to filter with grep . If, as in the example given, you would like to list only the masked unit files then you can use the following command:

systemctl list-unit-files | grep masked

You can also filter according to the type of unit file (Figure 7). The call

systemctl list-units --type=mount

Figure 7: Filtered list of unit files by type.

lists all units of the Mount type.

By the way, systemd without any arguments lists all of the units that have been started after the boot process.