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
| Runlevel | systemd target | Purpose |
|---|---|---|
| default.target | To start a system with a symbolic link to either graphical.target or multi-user.target | |
| 5 | graphical.target | Set the system to support graphical and text-based logins, and multiple users. |
| 3 | multi-user.target | Set the system to multi-user non-graphical system |
| halt.target | Halt the system without power off. | |
| poeweroff.target | Shut down and power off the system | |
| 1, single | rescue.target | Set the system to a rescue shell with su login prompt |
| emergency.target | Set su login prompt and system root mounted on /read-only | |
| 4 | custom.target | Set custom-defined 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.
| systemd command | SysVinit command | Description |
|---|---|---|
| systemctl start foo | service foo start | Start a service |
| systemctl stop foo | service foo stop | Stop a service |
| systemctl restart foo | service foo restart | Restart a service |
| systemctl reload foo | service foo reload | Reload the config file without interrupting operations |
| systemctl condrestart foo | service foo condrestart | Restart an already running service |
| systemctl status foo | service foo status | Check if service is running or not |
| systemctl or systemctl list-unit-files –type=service or ls /lib/systemd/system/*.service /etc/systemd/system/*.service | ls /etc/rc.d/init.d/ | List services that can be started or stopped List all services and units. |
| systemctl disable foo | chkconfig foo off | Turn the service off for the next reboot |
| systemctl is-enabled foo | chkconfig foo | Check whether a service is configured to start or not. |
| systemctl list-unit-files –type=service or ls /etc/systemd/system/*.wants/ | chkconfig --list | Print services and run-levels |
| systemctl list-dependencies graphical.target | chkconfig --list | grep 5:on | Print services that will be started on boot |
| ls /etc/systemd/system/*.wants/foo.service | chkconfig foo --list | List what levels a service is configured on or off. |
| systemctl daemon-reload | chkconfig foo --add | To reload new configurations |
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.
