GNU Shepherd - what is this alternative to systemD?

SysVinit

SysVinit – This system initialization, which is used in most Linux distributions. It starts all processes and services at startup systems and manages them based on scripts located in the /etc/init.d directory.

System V Init (abbreviated as Sysvinit) is a legacy of UNIX version 5 (V). Upstart was created for Ubuntu Linux and was briefly adopted by Red Hat Enterprise Linux as well. systemd is the newest and most popular system, based on the ideas of the launchd program from the Mac OS operating system.

For an operating system, one initialization system is sufficient, but for compatibility (maintaining the functionality of old programs), the installation may have one main system with elements of another.

The work environment may consist of a large number of processes. The initialization system is configured to start all the necessary processes in the right order. The intended result is called a “runlevel” in Sysvinit and Upstart, or a “target” in systemd. Turning off the computer and restarting the operating system are also considered results – here, too, you need to follow the correct sequence of actions and give the terminated processes the opportunity to save their data.

Many programs that form the work environment are specially designed or configured to run in the background, for example: acpid power manager, NetworkManager network manager, ntpd time service, smartd disk health monitoring service. When combined with initialization files, these background programs are called service daemons or services. Often the name ends with d (from daemon)/

The Sysvinit system starts and stops daemons in the order specified by the user/administrator; Upstart – forms a “tree” of responses to “events” (device discovery, mounting, daemon startup – these can be events that require a reaction in the form of launching another daemon); systemd – at startup, calculates a “tree” of daemons’ dependencies on each other and launches daemons in parallel if possible.

In addition to init, the initialization system contains daemon configuration files (initialization files) and control programs of the system itself.

Initialization files are text files with a special syntax (different for each system). For Sysvinit, they are located in the /etc/rc*.d/ directories (instead of an asterisk – a number or nothing), /etc/conf.d/ and there is also a file /etc/inittab; for Upstart – /etc/init/ and /etc/init.d/ and the inittab file; for systemd – /lib/systemd/, /run/systemd/ and /etc/systemd/. Some of the files are command shell scripts. A systemd runlevel or target can be thought of as a set of initialization files, and the system must execute them (by launching the appropriate programs). Systemd has an especially large number of files; in part, it creates them itself.

Traditional runlevel list:

0 – system stop (terminating processes from user space, stopping the kernel, and, if possible, turning off the power supply);

1 – single-user mode (command line available, no network, usually used as an emergency);

2 – multi-user mode (command line available, no network);

3 – multi-user mode (command line available, network possible);

4 – not used;

5 – multi-user mode (both command line and GUI are available, network is possible);

6 – reboot.

Run levels may be configured differently in different installations. In a home system, a level or goal is usually automatically set to correspond to a traditional 5. In Upstart, a level 2 corresponds to a traditional 5; Additionally, there are the designations N – “previous unknown” and S – 1 (from single user). systemd has shutdown targets (roughly equivalent to level 0); basic(1); multi-user(3); graphical (5).

Typically, initialization files are supplied ready-made, so the Linux installation already provides a ready-made working environment. Often, runlevel or target functionality is a little redundant, so you have to disable unnecessary daemons – just to save system resources.

Programs for GUI: Services Configuration Tool (system-config-services) for Sysvinit, Boot-Up manager (bum) for Sysvinit and Upstart, systemadm for systemd. Pseudographic ntsysv for Sysvinit.

The init process is the root ancestor of all processes except kernel threads. Therefore, the tasks of init additionally include “adopting” orphan processes and terminating them.

Almost all Linux distributions natively used SysV. The only exception was Gentoo, which used its own init system and Slackware, with BSD-style init.

Main features of SysV:

Writing service startup files in bash;
Sequential start of services;
Sort startup order using numbers in file names;
Commands to start, stop, and check the status of services.

There was no trace of any parallel loading, dependency system, launch on demand or automatic launch here.

Many years have passed since its development and due to some shortcomings, other systems were developed to replace it, although they had new functions and were more efficient, they were still compatible with SysV.

SystemD

For some, this initialization system is an evil devil who came straight from the secret laboratories of Microsoft in order to take over humanity. For others, it is a brilliant invention that helps system administrators and users. Both are partly right and partly wrong. It’s not for me to decide, the article is not about the problems and advantages of systemD. But you can speculate on this unfortunate topic in the comments.

More than a decade ago, systemd was announced and revolutionized system management for Linux distributions, thereby dividing Linux users into several camps. The quality and nature of the debate hasn’t improved much since the fiery wars of 2012-2014, and systemd still remains a largely under-understood tool from both a technical and public perspective, despite intense community attention.

The initialization and service management subsystem in Linux, which actually replaced the traditional init subsystem in the 2010s. The main feature is intensive parallelization of service launches during system boot, which can significantly speed up the startup of the operating system. The main unit of management is a module, one of the types of modules are “services” – an analogue of daemons – sets of processes launched and managed by subsystem tools and isolated by control groups.

primary goal systemd this speeds up the loading of the operating system due to parallelization launch processes and delayed start.

Parallelization is achieved by running unrelated services simultaneously. That is, if one service does not depend on the second and both have enough resources to start, then they start simultaneously.

Delayed start is achieved by preparing everything needed to start the service, but the service itself starts later, on demand. For example, all sockets are created to run a service, but the service will only start when the socket is accessed.

Systemd is the new Linux init system. It was introduced by default in Fedora 15, and is now used in almost all popular Linux distributions. It is not only an initialization process that supports a huge number of capabilities, but also a set of tools for managing services and these capabilities from the system. The main goal is to have complete control over all processes during their launch and throughout their execution.

Systemd is very different from all existing init systems in the way it works with services, and even service configuration files. There is no compatibility with SysV scripts; they need to be converted to linux systemd unit files.

Here are its main features:

Clear, simple and effective design;
Parallel loading of services based on dependencies;
Termination of additional processes is supported;
Supports native journaling using journald;
Supports job scheduling using Systemd timers;
Network management using networkd is supported;
Systemd-resolved is used to manage DNS;
Storing logs in binary files;
Saving the state of linux systemd services for possible recovery;
Improved integration with Gnome DE;
Launching services on demand;

OpenRC

Perhaps, in terms of popularity, I would put her in 2nd place.

A dependency-based init system that works in conjunction with the init program. It is fully compatible with Gentoo scripts, but can still be used on other Linux and BSD distributions.

The OpenRC system starts the necessary system services in a specific order at boot, manages them while the system is running, and stops them when the system shuts down. It can manage daemons installed from the Gentoo repository, optionally controlling the processes it starts, and has the ability to run processes in parallel (when possible) to reduce boot times.

OpenRC is an evolution of SysVInit, designed specifically for use on a number of Linux distributions, including Devuan. It retains the ease of use of SysVInit, but adds several new features:

Support for pausing and resuming processes: OpenRC allows you to easily pause and resume processes, which can be useful when updating or rebooting your system.
Using Sockets and Templates: OpenRC allows you to define services using sockets and templates, making it even more flexible and scalable.
SysVInit compatible: OpenRC is compatible with existing SysVInit scripts, making it easy to migrate from one init system to another.

It offers some outstanding features including:

It can run on many other Linux distributions, including Gentoo, as well as BSD.
Supports hardware initialization scripts.
Supports one configuration file
Per-service configurations are not supported
Works like a demon
Launching parallel services and much more

Runit

Quite a good initialization system, in my opinion. Overall it is very similar to init. Directories with initialization levels are stored in /etc/runit/level_number.

Runit is a simpler initialization subsystem that is designed to be lightweight and easy to use. It uses a simple, script-based approach to starting and stopping services, similar to SysV init. However, runit is more efficient than SysV init, with faster loading times and less resource usage.

Runit is a cross-platform init system that can run on GNU Linux, Solaris, BSD and MacOS. It is a great alternative to SysV with support for service health monitoring.

There are some interesting features here that are not found in other init systems:

Full control of services, each service is linked to its own directory;
Reliable logging and log rotation tool;
Fast boot and shutdown system;
Portability;
Easy creation of service configuration files;
A small amount of initialization system code.

Runit is a lightweight and fast init system designed to optimize booting and process management. It differs from SysVInit and OpenRC in the following features:

Based on the “supervise” concept: Runit uses the concept of “supervise” which makes it easy to start and manage services and processes.
Simplicity and reliability: Runit loads quickly and is small in size, making it ideal for resource-constrained systems.
Lack of support for pausing and resuming processes: Like SysVInit, Runit does not support suspending and resuming processes.