Table of contents of the article:
Systemd is a management and service mechanism, commonly known as a “system daemon”. It became critical in RHEL7 and later, taking on the responsibility of initializing and activating system resources and server daemons at system startup and during system execution. In simple words, systemd starts and manages all kinds of processes and services in Linux. Technically, it is an initializer program that brings the system to a defined state by activating all services and processes enabled in that state, using configuration files to know which services and processes are enabled in each state.
Evolution of init systems up to Systemd
systemd is the successor to the SysVinit and Upstart initializer programs. SysVinit, created in the 80s for 'UNIX System V' systems, has long been the standard until RHEL5. This program defined six system states, known as execution levels, and mapped all processes and services to these levels. However, SysVinit was intended for a static environment and did not handle hot-pluggable devices, such as USB drives, well.
Upstart was developed as a replacement for SysVinit to operate in a more flexible environment. It offered benefits such as event-based service management, asynchronous startup of services, and automatic restart of crashed services. Unlike SysVinit, Upstart did not use execution levels, but system events to start and stop services.
SysVinit
The history of SysVinit begins in the 80s, when it was introduced for 'UNIX System V' systems. At that time, it represented a major advance in the management of UNIX operating systems. SysVinit remained the standard for several operating systems, including Linux-based ones such as Red Hat Enterprise Linux (RHEL) until version 5, released in 2007. Its role was to organize the system startup process into six system states or execution levels, each representing a different state of system operation, from a full boot to a recovery or maintenance state. However, SysVinit had significant limitations: it was designed for a more static system environment and did not effectively handle new developments such as hot-pluggable devices.
Upstart
In response to the limitations of SysVinit, Upstart was developed, first introduced in Ubuntu in 2006. Upstart was an attempt to modernize the startup process, introducing concepts such as event-based service management and asynchronous service startup. This meant that services could be started or stopped in response to specific events, rather than in a fixed order as in SysVinit. Upstart's ability to automatically restart crashed services and better manage hot-pluggable devices was a marked improvement over its predecessor. However, Upstart also had its limitations, particularly in managing complex dependencies between services.
Systemd
Finally, systemd emerged as the successor to Upstart and SysVinit. Developed by Lennart Poettering and Kay Sievers of Red Hat, systemd was first released in 2010 and adopted by Fedora in 2011. It represents a radical change in the way Linux handles the boot process and supervision of services. Systemd introduces a more integrated and dynamic approach, managing not only the startup of services but also user sessions, mount points, sockets and other system resources. With features such as parallel startup of services, dependency resolution, and advanced management via cgroups, systemd has redefined efficiency and flexibility in managing modern Linux systems.
These transitions, from SysVinit to Upstart and then to systemd, reflect the continuous evolution of Linux operating systems and the search for increasingly efficient solutions suited to the needs of a rapidly evolving environment.
Features and Benefits of Systemd
Systemd, the modern initializer program, is used by most Linux developers, including RedHat (since version 7) and Ubuntu (since version 15.04). This system is more complex and offers many features and tools to manage services, devices, sockets, mount points, swap areas, drive types, targets, and much more.
The advantages of systemd include several significant features:
- Starting Services in Parallel Mode: Systemd is able to start services simultaneously instead of doing so sequentially. This parallel approach significantly reduces system startup time, improving overall performance. Several services can be started at the same time, as long as they have no dependencies on each other, optimizing the use of system resources.
- Automatic Dependency Resolution: Systemd intelligently manages dependencies between various services. It automatically identifies and resolves these dependencies, ensuring that services are started in the correct order. This eliminates the need for complex manual configurations, making the boot process more efficient and less error-prone.
- Ability to Restart Processes: Systemd has the ability to monitor and automatically restart services that stop unexpectedly. This ensures greater system stability, as critical services can be quickly restored without human intervention, minimizing downtime.
- Process Tracking and Association via Linux Control Groups (cgroups): Systemd uses cgroups to organize and manage processes efficiently. This allows resources such as CPU and memory to be allocated to specific groups of processes, improving resource management and isolating processes from each other, which increases system security and stability.
- Modern Hardware Support: Systemd offers broad support for modern hardware, including hot-pluggable devices such as USB drives and external disks. This means that systemd can dynamically manage these devices as they are connected or disconnected, improving the usability and flexibility of the system.
- Starting Daemon on Request: With systemd, daemons can be started on demand, without the need to restart the already running service. This is particularly useful for services that do not need to run continuously, but only when necessary, thus reducing the use of system resources.
- Creation of Running System State Snapshots: Systemd allows you to create snapshots of the current state of the system. These snapshots can be used to restore the system state to a previous point, a useful feature in the event of errors or malfunctions.
- Recording of Events: Finally, systemd provides an advanced logging mechanism, which allows you to track and analyze all events related to system services and processes. This is critical for debugging and keeping your system secure and running optimally.
These features make systemd a versatile and powerful tool for managing modern Linux operating systems, significantly improving the management, security and performance of system services and processes.
The concept of Unit in Systemd
In systemd, the concept of “Unit” represents one of the fundamental pillars on which this technology is based. A Unit in systemd is an object that represents a service, process, resource, or mount point within the system. Each Unit is described by a configuration file, which specifies how systemd should manage the corresponding service or resource. These configuration files are clear, structured and easily readable, and are usually found in /etc/systemd/system or /lib/systemd/system.
Units in systemd are categorized into different types, each of which has a specific purpose. The most common types include:
- Service Units: They manage system services, such as web servers or databases. They are identified by files with the extension
.service. - Socket Units: Used for managing network and IPC sockets, they allow inter-process communication. They are represented by files
.socket. - Device Units: Represent hardware devices and are created dynamically in response to hardware devices detected by the system. They are identified by files
.device. - Mount Units: Manage mount points in the file system, corresponding to files
.mount. - Target Units: They provide a mechanism for grouping different Units, facilitating the management of complex sets of dependencies and the coordinated startup of services. The files
.targetrepresent these groups.
Each Unit can have a series of directives that define how it should behave. These directives may include, for example, the order in which services should be started, dependencies between various services, or actions to take if a service fails. The systemd system parses these configuration files at system startup or when an administrator requests to start, stop, or restart a Unit.
The introduction of Units in systemd has greatly simplified the management of services and resources in Linux, making the process more scalable, manageable and understandable. This modular and unitary approach allows administrators to have more granular control over the behavior of services and the relationships between them, leading to more efficient and flexible system management.
Systemd as watchdog instead of supervisord
Systemd offers a built-in watchdog functionality, which allows system administrators to use it as an alternative to external tools like Supervisord for monitoring and managing services. The concept of watchdog in systemd is based on the ability to actively monitor services and processes, automatically restarting them in case of failure or unexpected shutdown. This translates into greater resilience and stability of the system.
The main feature of systemd as a watchdog is its native integration with the Linux ecosystem. Unlike Supervisord, which requires separate configuration and management, systemd is already an integral part of most modern Linux distributions, offering a unified solution for starting, supervising, and managing services.
To use systemd as a watchdog, administrators can take advantage of several directives in service unit configuration files. These include options like Restart=, which defines the conditions and frequency with which a service must be restarted in case of failure, and WatchdogSec=, which sets a timer for the watchdog. When a service does not report activity within the time specified by WatchdogSec=, systemd automatically intervenes to attempt to restore the service.
This feature makes systemd not only a system initializer, but also a powerful tool for maintaining the stability and reliability of critical services. With systemd, administrators can set up self-healing systems, where services are constantly monitored and kept in a working state without the need for frequent manual intervention. In this sense, systemd acts as a built-in safeguard, increasing system uptime and reducing potential downtime caused by service crashes or errors.
The Linux Community's Initial Rejection of Systemd
The introduction of systemd into the Linux world was not unanimously welcomed with enthusiasm. Instead, it has encountered significant resistance from a portion of the Linux community. This rejection was largely due to concerns about the complexity and centralization of the functionality that systemd introduced, breaking with the traditional Unix approach of “doing one thing and doing it well”. Some users and developers saw systemd as a usurpation of the traditional Linux approach, with its integrated system managing many aspects of the operating system, which were previously handled by a variety of smaller, modular tools. Additionally, the rapid adoption of systemd by many major Linux distributions has generated concerns about decreasing diversity and choice in the Linux landscape.
The Rise of Devuan as an Alternative for Veterans.
In response to the growing dissent against systemd, a new Linux distribution called Devuan was born (which we talked about in this article Devuan Linux: Freedom-Centered Alternative to the Debian Operating System). Launched in 2014, Devuan emerged as a fork of Debian, one of the most popular Linux distributions, specifically to offer a systemd-free alternative. Devuan's main goal was to maintain the legacy of traditional initialization, giving users freedom of choice and a less complex experience than systemd. This distribution has especially attracted traditional Linux users, those who prefer the modular and decentralized approach to system administration. Devuan has proven particularly attractive to Linux newbies, who are looking for a simple and less intricate operating system, and to those who want to have more manual control over various aspects of their operating system.
Command Guide from SysVinit to Systemd
The transition from SysVinit to systemd has led to significant changes in service and process management in Linux systems. For system administrators and users accustomed to SysVinit commands, adapting to systemd may seem like a challenge at first. This guide is designed to ease this transition by providing a direct comparison between traditional SysVinit commands and their systemd equivalents. This comparison will help users better understand how familiar commands have been transformed and how they can be used in the new system. Below is a table that illustrates the syntax of SysVinit commands and their counterparts in systemd, making it easier to update your skills and understand the new systems management paradigm.
Service Related Commands
| Post comments | SysVinit | Systemd |
|---|---|---|
| Start a service | service dummy start | systemctl start dummy.service |
| Stop a service | service dummy stop | systemctl stop dummy.service |
| Restart a service | service dummy restart | systemctl restart dummy.service |
| Recharge a service | service dummy reload | systemctl reload dummy.service |
| Check the status of a service | service dummy status | systemctl status dummy.service |
| Start a service at startup if it is already running | service dummy condrestart | systemctl try-restart dummy.service |
| Enable a service at startup | chkconfig dummy on | systemctl enable dummy.service |
| Disable a service at startup | chkconfig dummy off | systemctl disable dummy.service |
| Check whether a service is enabled at startup | chkconfig dummy | systemctl is-enabled dummy.service |
| Create a new service file or change the configuration | chkconfig dummy --add | systemctl daemon-reload |
Execution Levels – Runlevels
| Post comments | SysVinit | Systemd |
|---|---|---|
| System shutdown | 0 | runlevel0.target, poweroff.target |
| Single user mode | 1, s, single | runlevel1.target, rescue.target |
| Multi user | 2 | runlevel2.target, multi-user.target |
| Multi user with Network | 3 | runlevel3.target, multi-user.target |
| Experimental | 4 | runlevel4.target, multi-user.target |
| Multi user, with network, graphics mode | 5 | runlevel5.target, graphical.target |
| restarting | 6 | runlevel6.target, reboot.target |
| Emergency shell | emergency | emergency.target |
| Change to multi user runlevel/target | telinit 3 | systemctl isolate multi-user.target (OR systemctl isolate runlevel3.target) |
| Set multi-user target on next boot | sed -i 's/id:3:initdefault:/id:5:initdefault:/' /etc/inittab | ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target |
| Check the current runlevel | runlevel | systemctl get-default |
| Change the default runlevel | sed -i 's/id:3:initdefault:/id:5:initdefault:/' /etc/inittab | systemctl set-default multi-user.target |
Various Commands
| Post comments | SysVinit | Systemd |
|---|---|---|
| System shutdown | halt | systemctl halt |
| Shutting down the system | poweroff | systemctl poweroff |
| Restarting the system | reboot | systemctl reboot |
| System suspension | pm-suspend | systemctl suspend |
| Hibernation | pm-hibernate | systemctl hibernate |
| Follow the system log file | tail -f /var/log/messages o tail -f /var/log/syslog | journalctl -f |
New Systemd Commands
| Post comments | Systemd |
|---|---|
| Run a systemd command on a remote host | systemctl -H user@host |
| Check the startup time | systemd-analyze o systemd-analyze time |
| Kill all processes related to a service | systemctl kill dummy |
| Get logs of today's events | journalctl --since=today |
| Hostname and other host information | hostnamectl |
| System date and time with timezone and other information | timedatectl |
This table is not exhaustive, but covers the most commonly used commands, providing a handy reference for users moving from SysVinit to systemd. With this guide, the goal is to make the transition process as smooth and intuitive as possible.
Conclusion and advice
In the vast, ever-evolving world of Linux operating systems, Systemd is not just a trend, but a fundamental transformation that has redefined service and process management in Linux. For system administrators, learning and mastering Systemd are no longer options, but essentials.
The departure from the old sysvinit to the more modern and versatile Systemd is not only a technological step, but also a qualitative leap in the skills required of IT professionals. Most modern Linux distributions, from Debian to Fedora, from Ubuntu to CentOS, now rely on Systemd for service management. This shifts the needle from a traditional init system, which many have known and used for years, to a more complex and powerful ecosystem, where Systemd skills become essential.
Learning Systemd is not just an investment in maintaining your professional relevance; it's also an opportunity to explore new ways of performance optimization, resource management, and automation in Linux environments.
