System V style init and systemd in practice

Slashdot it! Delicious Share on Facebook Tweet! Digg!

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.

Table 7

Systemctl Options

make startable enable UNIT
make non-startable disable UNIT
for enable/disable: Immediately start/stop service --now
start start UNIT
stop stop UNIT
restart restart UNIT
read configuration again reload UNIT
Status inquiry status UNIT
masking, for special characteristics see section above mask UNIT
unmask (for special characteristics see section above) unmask UNIT
Show help for unit help UNIT
all unit files and their status list-unit-files
all units list-units
mounts -t mount
automounts -t automount
services -t service
devices -t device
sockets -t socket
targets -t target
bus name -t busname
swap space -t swap
timer -t timer
paths -t path
slices -t slice
scopes -t scope
snapshots -t snapshots
dependencies list-dependencies UNIT-FILE
failed units --failed
containers list-machines
Unit Enabled/Disabled?
enabled? is-enabled SERVICE
Change System State
power down and shut down poweroff
restart reboot
single user mode, system maintenance rescue
suspend mode suspend
switch runlevel isolate TARGET
Additional Actions
list unit file cat UNIT
list all properties show UNIT

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.

Buy this article as PDF

Express-Checkout as PDF

Pages: 1

Price $0.99
(incl. VAT)

Buy Ubuntu User

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Systemd as central control for the Linux system

    Some Linux followers see systemd as the best thing since sliced bread – for others, it's the work of the devil. However, it also has the stuff to clear out old trenches and form a unified base for Linux.

  • Innovation in the Linux environment

    Testers constantly encounter new trends in the experimental branches of Linux distributions. I look at who drives Linux forward and how the future is shaping up.

  • What is Upstart?

    Originally created for use in Ubuntu, Upstart is suitable for deployment in all Linux distributions as an alternative to the System-V init.

  • Installing and testing Nextcloud

    Leading ownCloud developers, including the project founder Frank Karlitschek, became dissatisfied with the direction of the project, so they started Nextcloud, a fork of the code and a new company. The goal is to create a better balance among the company, clients, and users. We take a look at how Nextcloud is faring.

  • Use multiple distributions at the same time with Bedrock Linux

    Bedrock transparently combines virtually any number of distributions with different architectures, package management, and init systems under a filesystem.