November 10, 2023

What is Systemd?

Systemd: the standard in Linux service management and its indispensability for system administrators.


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.


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.


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.


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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:

  1. Service Units: They manage system services, such as web servers or databases. They are identified by files with the extension .service.
  2. Socket Units: Used for managing network and IPC sockets, they allow inter-process communication. They are represented by files .socket.
  3. Device Units: Represent hardware devices and are created dynamically in response to hardware devices detected by the system. They are identified by files .device.
  4. Mount Units: Manage mount points in the file system, corresponding to files .mount.
  5. 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 .target represent 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,
Single user mode 1, s, single,
Multi user 2,
Multi user with Network 3,
Experimental 4,
Multi user, with network, graphics mode 5,
restarting 6,
Emergency shell emergency
Change to multi user runlevel/target telinit 3 systemctl isolate (OR systemctl isolate
Set multi-user target on next boot sed -i 's/id:3:initdefault:/id:5:initdefault:/' /etc/inittab ln -sf /lib/systemd/system/ /etc/systemd/system/
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

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.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top