Many major linux distributions have made the switch from older init systems like sysv to systemd. For newcomers, the features of systemd may be overwhelming at first, so this article will provide a rough outline of it's most common components and their purpose.
What is systemd?
Systemd is a modern init system and system manager, providing many essential features for linux operating systems. It is built to replace older software like the sysv init system, but also adds new features that were previously not available or required multiple pieces of software to be configured. The goal of systemd goes beyond the capablities of a simple init system, as it includes many different components to handle important tasks like booting, logging, device management, mounting filesystems, scheduling timers, setting time/date information, kernel parameters, hostname information, ... - the list goes on.
It is important to understand that systemd consists of many different modules, with many being optional. It aims to provide a consistent experience across common tasks and distributions, while maintaining backwards compatibility with it's predecessors.
Systemd units
The most fundamental resources in systemd are units. A unit is a single text file located somewhere in /etc/systemd, which may define an entity such as a system service, mount, target, timer or socket. Units have a great deal of control over how and when they run, allowing them to specify necessary dependencies, documentation, restarting policies and much more. They also have their output streams forwarded to journald for automated log collection, and have a streamlined way to handle failures and operator actions.
Boot process
The boot process of systemd differs a fair bit from that of sysv. Systemd has left the idea of static runlevels that sysv work with, instead switching to dynamic targets. A target is simply a unit file that defines what dependencies need to be started for this target (boot level) to be considered reached. The boot process goes through mutliple targets when starting, from single-user to multi-user environments, depending on the configuration. Since units have clear dependency trees, systemd can start multiple units in parallel, greatly improving boot speed and performance.
Service management
The traditional sysv service management using the /etc/init.d directory contents and the service command have been completely rewritten, now using the systemctl command to interact with services and journalctl to view logs. The new system has numerous advantages, for example unified logging and much easier debugging for administrators through systemctl status. Enabling services at boot is now done by running systemctl enable instead of the previous manual symlinking of service files to directories.
Systemd also introduced the new concept of user services, allowing unprivileged users to run managed services without needing administrator access.
Logging
Logs are collected from many parts of the system into the unified logging system journald, which comes bundled with systemd. Where previously administrators had to look into different files to find logs from the kernel, boot, mail, authentication or system logs, those are now combined into a single system. The journalctl command allows operators to filter through and view messages, with advanced filters to focus on logs from a specific process or viewing all messages at once for a broader picture of an incident.
Many systemd components also automatically forward their logs to journald, for example the output of services, timers, mounting errors etc.
Filesystem mounting
The traditional way of defining mounts in the /etc/fstab file has been replaced by systemd mount units. The contents of /etc/fstab are converted into these unit files automatically, so older software may still use this approach as before. Systemd mount units have many advantages, for example ensuring that a mount is available before a service that needs it is started, or dynamic mounts that are mounted on-demand when they are first accessed,
Networking
Taking over the responsibilities of inetd, sytemd-networking handles network interface configuration, automatic IP assigments over DHCP as well as more advanced features like DNS detection, VLAN configuration and VPN tunnels. It can be interacted with in a streamlined way through the systemctl command, like any other service.
Hostname, time & date
The utility tools hostnamectl and timedatectl provide a user-friendly interface for setting system metadata like timezones or short and long hostnames. They remove the need to manually edit configuration files, but also add new features or improved integration with the rest of the systemd suite.
Kernel parameter management
Kernel parameters can be configured through the sysctl command or config files in /etc/sysctl.d/*.conf. Systemd also adds the ability to set kernel parameters from unit files, adding the to the dependency chain or setting them after some other processes finished running.
Task scheduling
While cronjobs have long been a standard for automated background tasks in linux, systemd challenges them with timers by fixing their biggest problems: logging and failure detection. Systemd timers are simple units, so their logs are always collected and kept by journald, while errors are reported as for any other service failing. This provides an out-of-the-box solution to cron's long-standing issues, while also adding new features like running tasks only once, or relative to boot time. Systemd timers also run with a random delay between 0 and 60 seconds by default, to ensure multiple tasks scheduled for the same time don't actually start all at once (this can be disabled per-timer).
Device management
The udev standalone daemon is replaced by systemd-udevd, managing dynamic device node creation and removal, hardware events, and loading kernel modules. It provides better coordination between device detection and service startup, and integrates neatly with the systemd boot process.
Other components
The above list is only an overview of the most common components of systemd. The actual list of modules is significantly longer, including services like timesyncd for NTP support, resolved for DNS resolution or nspawn for enhanced chroot capabilities. An explanation of all components can be found in the systemd online documentation,
If your system is using systemd, it likely isn't using all of it's components. Have a look at the manual pages for your distribution and see what is available:
man -k systemd