System V style init and systemd in practice

systemd

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 halt.target , 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)
04
05 [Service]
06 ExecStart=/usr/sbin/atd -f
07 IgnoreSIGPIPE=false
08
09 [Install]
10 WantedBy=multi-user.target

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/……/…..target.wants 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.