System V style init and systemd in practice

Slashdot it! Delicious Share on Facebook Tweet! Digg!


In contrast to init, systemd, used by Ubuntu as from 15.04 – Vivid Vervet, starts services in parallel, making the operating system load faster. To ensure that this works, systemd itself sets up the sockets, which the services will use for communication once they are started. It then buffers any data to be handed to a service until the service has successfully started and can accept them.

If the service crashes, then systemd can restart it. All accesses by the client applications are buffered during the restart and are then processed by the daemon. The sockets set up by systemd can be transferred to other executing programs. These then assume control of the sockets.

It is possible to track processes that use cgroups . This feature is a kernel function, which collects processes together with their child processes into groups with a hierarchical structure.

A cgroup receives its name from the service, and a cgroup is formed for each service under systemd. This process grouping lets you avoid the type of chaos that can arise when there are numerous external processes under one service. Additionally, this approach prevents some of the external processes from surviving when the service crashes.

Not all of the services necessarily need to be started at system start. Instead, many can be executed when only when they are needed for the first time, which speeds up the boot process quite a bit. For this to happen, it is necessary to evaluate the activity on a network or IPC socket or a FIFO buffer. In this regard, systemd partly assumes functionality from inetd .

It is possible now to make a lot of invocations without being the root user. Additionally, systemd takes on the administration of mounts. It is also possible to take snapshots of the state of the system to later restore it if needed.

The runlevels continue to exist in the form of targets. You can figure out the purpose of the .target files from their names – for example, in , which powers down the system.

As with Upstart, systemd ignores the /etc/inittab file. However, the scripts for administration of services, known as RC scripts, are supported.

Configuring Services and Resources (systemd)

The directions for configuring and executing services are stored in so-called units. These are interchangeably named units or services . The various unit types are described in Table 4. The individual configuration files exist as plain text and are structured like INI files. Thus, it's possible to edit them with any text editor.

Table 4

Systemd Units

Unit Action
.automount Configures a mount point for automatic mounting of a data storage device.
.device The device intended for administration under systemd and that exists in the device tree of udev .
.mount The definition of a mount point administered by systemd and created by the fstab generator.
.path Starts additional services when objects in the indicated path have been modified.
.scope Are automatically created by systemd, and assist with the administration of system processes.
.service Information about processes
.slice Assists the resource administration of processes, is connected with the Linux Control Group Nodes .
.snapshot Makes it possible to restore the system state during a session that existed before a change.
.socket Describes a network, IPC socket or FIFO buffer, which systemd uses for a socket based activation. It always belongs to a .service entry that is triggered by activity on the socket.
.swap Specifications for external swap space using a device or file.
.target Bundling of several units into a synchronization point, previously referred to as runlevel.
.timer Sets a timer for a delayed or scheduled activity

Continuing from the example I used previously in the section on init, for the at daemon, you will find the structure of a typical unit file in Listing 5.

Listing 5

A Unit File for at

01 [Unit]
02 Description=Deferred execution scheduler
03 Documentation=man:atd(8)
05 [Service]
06 ExecStart=/usr/sbin/atd -f
07 IgnoreSIGPIPE=false
09 [Install]

These files and links to them are always stored in /lib/systemd so that they are accessible when booting. In the case of Debian and Ubuntu, you will find additional unit files stored in /usr/lib/systemd . Modified unit files are located in /etc/systemd/system . Files that the system created at runtime are located in /run/systemd/system .

If you want to create or modify your own service unit files, you can copy files your want to modify from /lib/systemd/…../ to /etc/systemd/system/ . You can also save new unit files there. However, it is not a good idea to ever save modified or new unit files in /lib/systemd/ because they will be overwritten during updates of systemd .

The unit files have various sections which contain specifications and assignments. Table 5 shows a large selection; the entire list can be found in the manpages [4]. A unit file will contain only one section in addition to [Unit] and, if necessary, [Install] .

Table 5

Sections and Specifications in Unit Files

Unit Action
[Unit] Contains descriptions of and dependencies on other units.
Description= Short description, states the functionality.
Documentation= Lists the manpages and where to find further information.
Requires= The units referred to here need to be active beforehand or simultaneously or starting the unit with this entry will fail.
Wants= Similar to Requires , these are necessary units that could not be activated but don't interfere with the start.
BindsTo= Similar to Requires , terminates the current unit when the indicated units are no longer active.
Before= The units indicated here are started after or at the same time as the current unit.
After= The units indicated in here are started before the current unit.
[Install] This section is read by the sysctl program for the enable or disable specifications during the work with the current unit. systemd does not need this section.
WantedBy= During execution of systemctl enable , symbolic links are set in the /etc/systemd/……/… directory pointing to /lib/systemd/…. . If not already present, the .target.wants directory is created under /etc/systemd/ .
Also= The calls sysctl enable and sysctl disable both process the units listed here.
RequiredBy= This is where dependencies are stated. If these are not available then sysctl cannot enable the current unit. In case of success, a .requires unit is saved to /etc/systemd/…. .
Service Start configuration for services.
Type=simple The call given for ExecStart is the main process for the indicated service.
Type=forking The call indicated by ExecStart terminates after the start has been successfully completed. The child processes run as main processes.
Type=oneshot As with simple , the next units are called after the end of the process which has been started. This is standard behavior when neither a Type= nor a ExecStart specification exist. Example: creating or cleaning directories.
Environment= Variable definitions.
ExecStart= Indication of the service to be started, if necessary with indication of the path and the variables set with Environment .
ExecStop= Commands to stop a service which starts with Type=oneshot
Restart= Indicates whether the service has to be restarted after its process has terminated or it is in timeout. If the process is terminated by systemd , it has no effect.
Restart=no The service does not restart.
Restart=always Restart independently of the exit code of the process.
Type= Specifies the filesystem.
Options= Mount options (rw , ro , etc.).
[Path] Specifies a filesystem path which can be monitored by systemd .
PathExists= Checks to see whether the path exists.
PathModified= Monitors modification to the given path.
Unit= The unit to be activated.

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.