systemd

Systemd is a modern init system and service manager for Linux operating systems.

systemd is the mother of all processes and it is responsible for bringing the Linux host up to a state in which productive work can be done. Some of its functions, which are far more extensive than the old init program, are to manage many aspects of a running Linux host, including mounting filesystems, and starting and managing system services required to have a productive Linux host. 

It is designed to provide better performance, greater parallelism during boot, and more features compared to traditional init systems like SysVinit.

systemd mounts the filesystems as defined by /etc/fstab, including any swap files or partitions. At this point, it can access the configuration files located in /etc, including its own. It uses its configuration file, /etc/systemd/system/default.target, to determine which state or target, into which it should boot the host. The default.target file is only a symbolic link to the true target file. For a desktop workstation, this is typically going to be the graphical.target, which is equivalent to runlevel 5 in the old SystemV init. For a server, the default is more likely to be the multi-user.target which is like runlevel 3 in SystemV. The emergency.target is similar to single user mode.

Here’s a detailed breakdown of the systemd boot and startup processes:

1. System Initialization by the Kernel

• Kernel Boot: The Linux kernel is loaded into memory by the bootloader and initializes the system hardware.
• Initramfs: The kernel mounts the initial RAM filesystem, which contains necessary drivers and tools for mounting the real root filesystem.

2. Systemd Initialization

• PID 1: The kernel starts the systemd process as the first user-space process (PID 1).
• System Manager: systemd takes over the boot process, initializing the rest of the system.

3. Unit Files and Targets

Systemd uses unit files to manage services, devices, mount points, sockets, and more. These unit files are typically located in /etc/systemd/system/ and /lib/systemd/system/. Here are the main types of unit files:

• Service Units (*.service): Define services to be started and managed by systemd.
• Socket Units (*.socket): Define sockets that systemd should create and listen on.
• Device Units (*.device): Manage device nodes in the /dev/ directory.
• Mount Units (*.mount): Control filesystem mount points.
• Automount Units (*.automount): Manage automount points.
• Swap Units (*.swap): Define swap spaces.
• Target Units (*.target): Group units for synchronization purposes, similar to runlevels.

4. Default Target

The comparison of the systemd targets with the old SystemV startup runlevels. The systemd target aliases are provided by systemd for backward compatibility. The target aliases allow scripts—and many sysadmins to use SystemV commands like init 3 to change runlevels. Of course, the SystemV commands are forwarded to systemd for interpretation and execution.

Table 1: Comparison of SystemV runlevels with systemd targets and some target aliases.

Each target has a set of dependencies described in its configuration file. systemd starts the required dependencies. These dependencies are the services required to run the Linux host at a specific level of functionality. When all of the dependencies listed in the target configuration files are loaded and running, the system is running at that target level.

systemd also looks at the legacy SystemV init directories to see if any startup files exist there. If so, systemd used those as configuration files to start the services described by the files. The deprecated network service is a good example of one of those that still use SystemV startup files in Fedora.

Below Figure is copied directly from the bootup man page. It shows the general sequence of events during systemd startup and the basic ordering requirements to ensure a successful startup.

The sysinit.target and basic.target targets can be considered as checkpoints in the startup process. Although systemd has as one of its design goals to start system services in parallel, there are still certain services and functional targets that must be started before other services and targets can be started. These checkpoints cannot be passed until all of the services and targets required by that checkpoint are fulfilled.

So the sysinit.target is reached when all of the units on which it depends are completed. All of those units, mounting filesystems, setting up swap files, starting udev, setting the random generator seed, initiating low-level services, and setting up cryptographic services if one or more filesystems are encrypted, must be completed, but within the sysinit.target those tasks can be performed in parallel.

After the sysinit.target is fulfilled, systemd next starts the basic.target, starting all of the units required to fulfill it. The basic target provides some additional functionality by starting units that re required for the next target. These include setting up things like paths to various executable directories, communication sockets, and timers.

Finally, the user-level targets, multi-user.target or graphical.target can be initialized. Notice that the multi-user.target must be reached before the graphical target dependencies can be met.

If the multi-user.target is the default, then you should see a text mode login on the console.

The sysinit.target starts up all of the low-level services and units required for the system to be marginally functional and that are required to enable moving on to the basic.target.

• Default Target: Systemd determines the default target to boot into, which is typically set to default.target. This is often a symlink to multi-user.target (for a non-graphical multi-user system) or graphical.target (for a graphical system).

5. Dependency Resolution

• Dependency Graph: Systemd analyzes the dependency graph of all enabled units to determine the order of starting services. It can start many services in parallel if they don’t depend on each other.

6. Starting Services

• Service Initialization: Systemd starts services based on the resolved dependencies. Each service unit file specifies how and when the service should start, its dependencies, and any conditions that must be met.
• System State: Systemd transitions the system from the early boot state to the final operational state by activating various units defined in the default target.

7. Handling User Login

• Login Service (getty): For non-graphical systems, systemd starts getty on virtual terminals to provide login prompts.
• Display Manager: For graphical systems, systemd starts the display manager (e.g., GDM, LightDM) to provide a graphical login screen.

8. User Session Management

• User Services: Once a user logs in, systemd starts a user instance (systemd --user) to manage per-user services and applications.
• Session Initialization: User-specific services and environment settings are initialized, and the user’s desktop environment or command shell is started.

Key Features of Systemd

• Parallelization: Systemd can start services in parallel, significantly speeding up the boot process.
• On-Demand Starting: Services can be started on-demand, triggered by socket activation or other events.
• Unified Configuration: Unit files provide a consistent and unified way to configure services and system resources.
• Logging: Integrated logging with journald collects and stores log messages from the kernel, init process, and user-space services.
• Cgroup Integration: Systemd uses Linux control groups (cgroups) to manage and isolate resources for services and users.

Summary

1. Kernel Initialization: Kernel loads and mounts the initramfs.
2. Systemd as PID 1: Kernel starts systemd, the first user-space process.
3. Unit Files and Targets: Systemd reads unit files and determines the default target.
4. Dependency Resolution: Systemd resolves dependencies and prepares to start services.
5. Starting Services: Systemd starts services in parallel according to the resolved dependencies.
6. User Login: Systemd handles login prompts or graphical login managers.
7. User Session Management: Systemd starts user-specific services and environments.

Systemd modernizes the Linux boot and initialization process, providing a flexible, fast, and consistent way to manage system and user services.