OpsInit: Introduction to Systemd

Table of contents

Reading Time: 4 minutes

Introduction

Let’s talk about init processes, What are they and how they work? Init stands for initialization which implies that it is the first process that runs when we start our system. This process is the father to all the processes.

There are some disadvantages due to which it has been replaced by Systemd. These
disadvantages are as follows:

Starts tasks serially. It waits for one process to stop before the next one
can start.
Startup processes, if blocked on I/O, can cause long delays in the boot.

Let’s Talk About Systemd

It is, in simple terms, a boot manager. It provides us with the following features:

Aggressive parallelization capabilities.
On-demand starting of daemons.
Keeping track of processes spawned through it.
Can handle process dependency.
Device-based activation of processes:
- As soon as we connect a device processes related to that device will be automatically be spawned.
Path-Based activation:
- If the directory/file used by a daemon gets changed then the daemon will
  restart automatically to incorporate the change.

Where Can We Use It?

Let us take some scenarios where we can find it useful:

Path-Based Activation:
Scenario: We do not want to stop our service just because we changed the configuration of the process. This can easily be handled by Systemd.
On-Demand Starting/Stopping services:
Scenario: Usually we use databases which are invoked by using first changing to
the directory and then executing it’s bin or `.sh` file.
We can have the service running in the background and we can get the status with
one-liner commands.

Systemd Service, How do they look?

Let’s assume that we have a service which starts a database for us. If we want to
leverage the advantages offered by Systemd service then we should create a
daemon of this process. Which isn’t demonic as it may sound (pun intended).

We create daemon services by creating the Systemd unit files, we can take a look
at some of the daemon files already present in our system by hitting `ls` on the
following locations:

/usr/lib/systemd/user/ : We often use RPM packages to install certain services
These services often have Systemd files for that services
which gets copied at this location.
/etc/systemd/system : This locations is for unit files created or customized by
system admin.

The Naming convention for Unit files follows this syntax: unit_name.type_extension. If we hit ls on any of the above locations we can see the following extension types :

File Extension	Description
.service	A system service
.target	A Group of Systemd Services.
.device	Device file recognized by Kernel.
.path	A file or directory in a file system.
.socket	An inter-process communication socket.

The Structure Of Unit Files

It contains 3 sections:

[Unit]:
– contains meta-data information like description and nick-name for the service.
– sets dependencies to other units.
[Unit Type]:
– it depends upon the extension we have used when we named our unit file. For example, if we named it .service then [Unit type] will be [Service].
[Install]:
– contains information about the unit for installation to use when a user hit systemctl enable or systemctl disable

Each of the 3 sections defined above has options within it. Let us discuss some of the most commonly used options.

Unit Section Options:

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters

Show hidden characters

	[Service]
	Type=notify
	ExecStart=/usr/bin/pulseaudio —daemonize=no
	Restart=on-failure

view raw

pulseaudio.service

hosted with ❤ by GitHub

Option	Description
Description	Description of the unit file. Displayed when we check the status of the service.
After	Defines the order in which units shall start. Out unit will only start after `intialise_my_server.service` will start If we use `Before` in place of `After` our service will start first and will not wait.
Wants	Configures weaker dependencies, which means that if units defined in `Wants` option fails, the unit will not fail.
Conflicts	Configure the dependencies which we do not want to have when our unit is running.

Service Section Options [Unit_type]:

Option	Description
ExecStart	Specifies the command or Script to be executed when the unit is started.
Type	Defines the unit process startup type, it affects the functionality of ExecStart. They are as follows: simple: Default value, The process started by ExecStart is the main process of a unit. forking: Process started by ExecStart spawns a child process that becomes the main process of the service. Parent which started the child then dies. oneshot: Similar to simple but the process exits before starting consequent units. notify: consequent units are started only after a notification is sent by our unit.
ExecStop ExecReload	Specifies commands/scripts to be executed when the unit is stopped [ExecStop]/reloaded[ExecReload]
Restart	Configure whether the service shall be restarted when service process exits, killed, or timeouts. Options: on-success: Unit will be restarted when it has exited cleanly. on-failure: unit will be restarted when it has failed/ exited erratically. no: the unit will never be restarted. always: The unit will always be restarted. No matter what happens.

Install Section Options

Show hidden characters

	[Install]
	Also=pulseaudio.socket
	WantedBy=default.target

view raw

Install_section.service

hosted with ❤ by GitHub

Option	Description
Also	Specifies the list of units to be installed/uninstalled whenever we enable/disable our unit respectively.
WantedBy	Provides the name of a unit for which a symlink is created in .wants directory of this unit whenever this unit is enabled. What it means is, `default.target` dependencies specified in its `Wants` or `Requires` section will become the dependencies of our unit.