OpsInit: Introduction to Systemd

Reading Time: 4 minutes


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

ExecStart=/usr/bin/pulseaudio —daemonize=no
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

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.
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.
    • 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

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

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.

That’s it, for now, folks, We will see some example/s in the next blog.


  • The Systemd Documentation.
  • Check out the man page of Systemd hit this command on terminal:
    man systemd.unit | man systemd.service


Written by 

Software Consultant