Systemd is primarily an init system for Linux operating systems. It’s main task is to initialize the components that must be started after the Linux kernel is booted.

An init system start system services, load drivers, bring up network interfaces and more at startup, allowing for the system to reach a usable state.


These components will be called user space (or userland) and refers to all code that runs outside the operating system’s kernel.

To find out what init system your Linux OS is using, you can use one of the following commands

$ cat /proc/1/comm

The following commands will show a symbolic link to the actual init system
$ stat /proc/1/exe
$ stat/sbin/init


The start of these components will also be named to bootstrap user space

In general, bootstrapping usually refers to a self-starting process that is supposed to continue or grow without external input.
Source: https://en.wikipedia.org/wiki/Bootstrapping


init system
In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel during the booting process; a kernel panic will occur if the kernel is unable to start it. Init is typically assigned process identifier 1.

Source: https://en.wikipedia.org/wiki/Init

$ sudo ps -aux


The name systemd adheres to the Unix convention of naming daemons by appending the letter d.

But systemd is not just an init system as mentioned, it is a software suite that provides several system components and tools for Linux operating systems.


We are interested in this post in its capabilities to manage these components (services called daemons in Linux) by using the systemctl command.

The systemctl command is the central management tool to manage the init system. These services resp. daemons are also called units in systemd.

Units will not only for daemons created but also for timer, mount points, sockets, swap storage and devices.


System wide Units (Ubuntu)

  • /lib/systemd/system: all files from units they were pre-installed by the system. You shouldn’t edit these files.
  • /etc/systemd/system: all files from system wide units they were installed or edited by user’s.

In case there where units with the same name in both paths, the units from /etc/systemd/system will be loaded by the kernel. You will also find under /etc/systemd/system units they link to the /lib/systemd/system unit.


You will also see the path of a unit by using the following command to check the status of the service

$ systemctl status servicename.service


User Units (Ubuntu)

systemd user units are nearly the same as system wide units but they will not start automatically at booting the system.

User units wont start until the user they enabled it is logon on to the system interactive or remote per SSH. Per default user units runs with the user account it was enabled.

Below the path for the user units

  • /usr/lib/systemd/user: pre-installed files for user units
  • /etc/systemd/user: units created by the user
  • ~/.local/share/systemd/user: local units just for the user
  • ~/.config/systemd/user: all user units created or edited by the user itself


As mentioned I will focus on managing the service units below. The service units had the .service suffix which you do not need to append for most services and systemd will recognize without.



Show actual Version of Systemd and Systemctl

$ systemd –version
$ systemctl –version


List active Systemd Services

$ systemctl list-units –type service


List all Units loaded or attempted to load

$ systemctl list-unit-files –type=service



Starting and Stopping Services

To start a service (daemon)
$ sudo systemctl start servicename.service
or
$ sudo systemctl start servicename

e.g
$ sudo systemctl start ssh

To stop a service (daemon)
$ sudo systemctl stop servicename.service


Restart and Reloading Services

To restart a service
$ sudo restart servicename.service

To reload a service (just reload its configuration and still provide the service running)
$ sudo reload servicename.service


Enable and Disable Services

To enable the start of a service at boot automatically
$ sudo enable servicename.service

To disable the service will start automatically
$ sudo disable servicename.service


Check the Status of a Service

$ systemctl status servicename.service

You can also check if a service is enabled or disabled by using

$ systemctl is-enabled servicename.service

Further you will also see if a service is enabled or disabled by using the above

$ systemctl status servicename.service

By default apache2 is enabled after installing it, I explicitly disabled it to show the status in the output of this command.


To check if a service is active and running

$ systemctl is-active servicename.service


Show Dependencies

$ systemctl list-dependencies servicename.service


Prevent Services from startet manual with Mask

To prevent a service even if disabled can be started manual, use the following command

$ sudo systemctl mask servicename.service

You can unmask a service in order it can be started manual by
$ sudo systemctl unmask servicename.service



Edit Services

Systemd services can be modified using the following command

$ sudo systemctl edit httpd.service

This creates an override file /etc/systemd/system/httpd.service.d/override.conf and opens it in your text editor. Anything you put into this file will be added to the existing service file.

To completely replace (instead of just add to/modify) an existing service file, use systemctl edit –full, e.g. systemctl edit –full httpd.service. This will create /etc/systemctl/system/httpd.service, which will be used instead of the existing service file.

Source: https://docs.fedoraproject.org/en-US/quick-docs/understanding-and-administering-systemd/



Manage Run Levels

On Unix-like systems such as Linux, the current state of the OS is known as runlevel. The runlevel determines what services need to be started and running. Under the SysV init system the runlevel are identified by numbers.

In systemd runlevels was replaced with targets.

  • Run level 0 –> poweroff.target 
  • Run level 1  –> rescue.target 
  • Run level 3 –> multi-user.target 
  • Run level 5 –> graphical.target 
  • Run level 6  –> reboot.target 
  • Emergency –> emergency.target


To change the runlevel resp. now target you can use the following command for example to switch to runlevel 3 –> multi-user.targe

$ sudo systemctl isolate multi-user.target

You can also change the default target which is normally graphical.target (runlevel 5) as follows

$ sudo systemctl set-default multi-user.target


To list active targets run the following command

$ systemctl list-units –type target




Links

How To Use Systemctl to Manage Systemd Services and Units
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

User space and kernel space
https://en.wikipedia.org/wiki/User_space_and_kernel_space

Bootstrapping
https://en.wikipedia.org/wiki/Bootstrapping

Systemd on Linux – Manage Services, Run Levels and Logs
https://www.linuxbabe.com/command-line/systemd-services-run-levels-logs

How to Change Runlevels (targets) in SystemD
https://www.tecmint.com/change-runlevels-targets-in-systemd/

The Story Behind ‘init’ and ‘systemd’: Why ‘init’ Needed to be Replaced with ‘systemd’ in Linux
https://www.tecmint.com/systemd-replaces-init-in-linux/