Init vs systemd

Overview

Definition of systemd

According to Lennart Poettering, the developper of systemd:

"systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting devices."

In "Simpler Language":

systemd is a more efficient method of controlling processes. It has the flexibility to start services in parallel, and have them communicate with each other, even if they are restarted (respawned). This is particularly useful for system administrators to temporarily service or update services without affecting the other dependent services.

The Old Way: init

Upon computer boot-up, and after the Kernel process is started, it traditionally launched the init process (usually PID 1). This important process manages (launches) other common services. The init process also has the ability to manage process (for example, respawing or "restarting" processes if they are terminated for some reason). In many ways, the init process is the "ancestor process" and any process that is currently running on the Unix/Linux system is either directly or indirectly related to the init process. Traditionally, the init program would run default processes that were defined in "shell scripts" contained in appropriate run-level directory. The run level is a defined state that the Unix/Linux system is currently in (for example, graphical-mode, text-based mode with networking, text-based mode without networking, etc).

pstree command displaying relationship between init and other services (processes).

Traditional method of managing services via run-levels. Each run-level directory contains scripts to sequentially launch services.

Why Switch to systemd?

Why switch to systemd when the concept of init and run levels seemed to work for 40 years?!? If it isn't broke, why try to fix it?!?

Yes, the concept is very easy to understand. On the other hand, with modern operating systems, there is pressure to "evolve" into more efficent running operating systems. For example, in many ways both Apple creators and Unix/Linux creators have influenced each other to build better operating systems over the past decade. The Apple Mac OSX operating system uses a variation of the Unix kernel. On the other hand, Unix/Linux developpers have noticed Apple's method of running services in parallel as opposed to in sequence.

Here is an example comparing init vs systemd:

(Reference: (beyond init: systemd) )

The init process may force certain services to be launched in a particular sequence. For example, the Bluetooth process cannot launch until the avahi process launches. On the other hand, the avahi process cannot launch until the D-BUS process launches, which cannot start until the syslog process is launched.

 | syslog
 V
 | D-Bus
 V
 | Avahi
 V
 | BlueTooth
 V

The traditional method can take time, and cause problems if a dependent process restarts.

On the other hand, systemd launches all process in parallel (at same time), but allows them to communicate with each other (via sockets) for "on-demand" communication. This helps to improve efficiencies when running services, and makes it easier for system administrators to update services without "side effects" to the other dependent services.

 | syslog  | D-Bus  | Avahi  | BlueTooth
 V         V        V        V

Note: Although Linux operating systems (other than Fedora) still use init, systemd is compatible with init, but systemd is likely to replace init for all Unix/Linux distributions in the future...

The New Way: systemd

System Units

Services are organized in terms of units which consist of a name and a type which correspond to a configuration file.

There are seven different types of units:

service	Processes (daemons) start/stop/restart/reload
socket	Define communication channel (for other services)
device	Recognise hardware device (plug & play)
mount	Connect device to file system
automount	Automatically connect device to file system (bootup)
target	Groups related services (dependency)
snapshot	Reference other units

NOTE: For this tutorial resource, we only focus on the service unit.

systemd Command Usage

Below are examples of systemctl commands:

Listing Running Services	systemctl list-units
Display Status of all Services (pipe to grep for just one service)	systemctl list-units --all
Confirm Status of Running Service	systemctl status name.service
Stop Service	systemctl stop service-name
Start Service	systemctl start service-name
Restart Service	systemctl restart service-name
Display Service Status	systemctl status service-name
Enable Service	systemctl enable service-name
Disable Service	systemctl disable service-name

Graphical Version
The systemadm command provides a graphical tool to manage services, but is still in the development stage and should not be used.

Changing the Runlevel

According to WIKIPedia (http://en.wikipedia.org/wiki/Runlevel)"

"Runlevel" defines the state of the machine after boot. Different runlevels are typically assigned to:

• single-user mode
• multi-user mode without network services started
• multi-user mode with network services started
• system shutdown
• system reboot

The exact setup of these configurations will vary from OS to OS, and from one Linux distribution to another.

Refer to the following link to change the runlevel of your system using systemctl:

http://fedoraproject.org/wiki/Systemd#How_do_I_change_the_runlevel.3F

Additional Resources

• YouTube Video: beyond init: systemd