Top reasons why systemd is a practical tool for sysadmins

System daemon or systemd is a service and system manager for Linux. systemd is compatible with LSB and SysV and is available in all major distros. Certainly, as you would expect with Linux, systemd is not the only init system available. Other alternatives include OpenRC, SysVinit, runit, and s6. However, the versatility, ease of use, and power of the systemd tool make it practical for users and system administrators alike.

To manage systemd, use the systemctl command, which utilizes both the functionality of SysVinit’s service and chkconfig commands. It manages system units which are representations of system services and resources. You can use it to enable or disable services permanently or for the current session.

Why systemd is a practical tool for sysadmins

This article will highlight reasons why sysadmins find systemd a practical tool to manage services and resources in a Linux system. Systemd provides the following:

•  Aggressive parallelization.
• Starting services using socket and D-Bus activation.
• Tracks processes using Linux cgroups.
• Supports on-demand starting of daemons.
• Implements a transactional dependency-based service control logic.
• Supports snapshots and restoring of system state.
• Maintains filesystem mount and automount points.

systemd

Boot management

A complete Linux boot process involves hardware boot which initializes the system hardware, Linux boot which loads the Kernel, then systemd, and Linux startup, where init or systemd prepares the operating system processes. Linux startup process begins when the Kernel transfers control of the host to the systemd. Systemd then starts as many services as possible in parallel. It, therefore, speeds the overall startup and gets the operating system to a login screen faster than other init processes.

Some users prefer systemd because it manages almost every aspect of your system. For example, it can manage running services, hardware, processes, and groups of processes, file-system mounts, provide comprehensive status information on the processes, and much more.

systemd generates data from your system uptime since a recent boot time. The data can serve as a health check for your system and is often important when monitoring or diagnosing system problems. In addition, it is often important for sysadmins to understand and differentiate the role of each boot process to better manage and troubleshoot system boot and processes.

systemd logs

System logs provide a history of your computer activity. They store information about when services launched, system jobs, services running in the background, failed activities, and so much more. To troubleshoot a system, you can review logs with the journalctl command.

$ journalctl --pager -end

The flag –pager -end starts your log review at the end of the journalctl output.

systemd maintains a “catalog” of errors, messages, possible solutions, pointers to support forums, and developer documentation. It highlights important context as there could be many logs messages which could go unnoticed.

Run the following command to integrate error messages with explanatory text:

$ journactl --pager -end --catalog

It is often good practice to narrow down and limit your log output when troubleshooting a system. For example, you can specify a boot session with the –boot option and a session index.

$ journalctl --pager -end --catalog --boot 37

You can also view logs for a specific systemd unit. For example, to troubleshoot the SSH service, you can specify –unit sshd to view logs for the sshd daemon.

$ journalctl --pager -end \
--catalog --boot 37 \
--unit sshd

systemd services

The core task of systemd is to boot your computer and handle system service management. It ensures that a service starts, continues to run during a session, restores a crashed service, or even stops it when required. You can manage and control systemd services using the systemctl command.

The following examples demonstrate how to manage systemd services:

To view unit files of a service (httpd):

# systemctl cat httpd

To modify unit files with local changes:

# systemctl edit httpd

To activate a service (httpd):

# systemctl start httpd

To deactivate a service (httpd):

# systemctl stop httpd

To restart a service (httpd):

# systemctl restart httpd

To show the status of service (httpd):

# systemctl status httpd

Finally, to enable service on system boot (httpd):

# systemctl enable httpd

To disable service (httpd) not to start during boot:

# systemctl disable httpd

To check if service (httpd) is enabled or not:

# systemctl is-enabled httpd

To prevent a service from starting unless unmasked:

# systemctl mask httpd

Running the above commands gives a sysadmin more useful information about a service, whether they are running or not. For example, with a single systemctl status command, you get information on the running or not running status of a service, running tasks, memory, and some of the most recent log entries. In essence, it simplifies troubleshooting a problem because you will get more information right at the start.

Fun Fact:  Lennart Poettering is the primary developer of systemd.

systemd timers

systemd uses timers to schedule and run tasks or events repeatedly after a system boot. Systemd timers can be seen as an alternative to both cron and anacron. As we learned in our previous article on scheduling tasks with cron, you can use it to schedule events at a granularity ranging from minutes to months or even more. However, a cron job fails if your system happens not to be running when the execution time occurs. However, sysadmins can use anacron to prevent such job fails. But to get the best of both cron and anacron, sysadmins often use systemd timers which offer better management options.

systemd timers allow scheduling of tasks to minute granularity, ensuring that tasks will be executed when the system is powered back up even if it was off during the expected execution time. Moreover, timers are available to all users, and you can test and debug them before implementing them in your system. One caveat, however, is that systemd timers require at least two configuration files and might be more involving to configure than cron and anacron.

To configure a systemd timer, you will require the timer unit and the service unit files. The timer unit file defines the schedule, while the service unit defines the tasks.

Basic systemd timer operations

Once you have created a service, you can perform the following operations:

First, to enable a user service (foo.service):

$ systemctl --user enable foo.service

Second, to perform a test run of the task:

$ systemctl --user start foo.service.

Third, to enable and start a user timer for a service:

$ systemctl --user enable foo.timer
$ systemctl --user start foo.timer

Fourth, to check and monitor the status of a service:

$ systemctl --user status foo
$ systemctl --user list-unit-files

Finally, to manually stop a service:

$ systemctl --user stop foo.service

To permanently stop and disable the timer and the service:

$ systemctl --user stop foo.timer
$ systemctl --user disable foo.timer
$ systemctl --user stop foo.service
$ systemctl --user disable foo.service

To reload the daemon config

$ systemctl --user daemon-reload
$ systemctl --user reset-failed

To list active timers:

$ systemctl list-timers

To list loaded but inactive timers:

$ systemctl list-timers --all

systemd targets

A systemd target is a set of systemd units that should be started to reach the desired state. Targets are not too dissimilar to services and timers. They are defined by a unit file and can be started, enabled, and stopped in the same way as timers. However, targets are unique in that they group other unit files in an arbitrarily significant way.

systemd targets create an easy way for sysadmins to collect timers, service, or other targets together to represent a specified state for your system. In essence, reboot, shut-down, and power-off are also systemd targets.

Examples of systems targets

Basic systemd target commands

To list all available targets:

$ systemctl list-unit-files –type target

To view target dependencies:

# systemctl list-dependencies rescue.target | grep target

systemd targets dependencies

To check the default target:

# systemctl get-default
graphical.target

To switch to the multi-user.target:

# systemctl isolate multi-user.target

systemd service security

systemd can offer a practical way to provide extra protection for custom services and services shipped with your Linux distro. You can also use the systemd-analyze security command to get a quick security audit of services. It will list a service unit with its associated security exposure score rating from 0-10.

# systemd-analyze security

systemd service security

Note: Lower scores are more secure but are entirely based on a service’s utilization of security features provided by the systemd. It does not consider the built-in security features of programs or those provided by access control policies like SELinux.

You can also analyze a service’s security directives with the following command:

# systemctl-analyze security foo.service

The command above will generate a report of security directives applied to foo.service. The report will highlight sections and configurations that need improvement for better security. For example, you can change read-access and write access policies or edit a service unit for security hardening.

To make changes to a service unit:

# systemctl edit foo.service

To make systemd aware of the changes to the override file:

# systemctl daemon-reload

To make changes take effect

# systemctl restart foo.service

Systemd equivalent of SysVinit commands.

Learn more from systemd.unit manual pages or a guide to systemd from the Fedora project that I find very informative with extensive examples and explanations. 

Conclusion

systemd can provide efficient ways for system management and troubleshoot through log introspection. Users can create a robust, versatile, and secure system through its major components such as services, targets, timers, logs, and security features. If you have used SysVinit, you will appreciate its open nature scripts. systemd, on the other hand, is easy to use, powerful, and can manage every aspect of a Linux system.

The next article in this series will look at scheduling tasks with systemd timers to automate the boring tasks in your Linux system.