In this tutorial, we'll learn how to manage system settings and services using systemd. systemd organizes tasks into components called units and groups of units into targets. We'll learn how to manage system services by using systemd to start, stop, enable and disable a service, send termination signals, use the systemctl command and manage systemd targets.

Requirements

• Basic understanding of Linux commands
• Basic understanding of Linux processes, daemons and control groups

What is systemd?

systemd is a system and service manager for Linux operating systems. It is the default initialization system for major Linux distributions. systemd is not directly initiated by the user, but installed through the /sbin/init and started during the early boot. systemd acts as the init system that brings up and maintains user space services when run as the first process on boot (PID 1). PID 1 is known as init and is the first Linux user-mode process created. It runs until the system shutdown.

systemd owns PID 1, as you can see with the command ps 1, and is started directly by the kernel. All other processes are started directly by systemd or one of its child processes. systemd mounts the host's file system and manages temporary files. It is backward compatible with the SysV init scripts. SysV is an initialization system that predates systemd.

In systemd, a unit is a resource that the system knows how to operate on and manage. This is the primary object that the systemd tools use. These resources are defined with configuration files called unit files. You can create your own unit files in /etc/systemd/system to automate tasks like backup management or monitoring your local cloud folder.

systemctl is the central management tool for controlling the init system. It is used to examine and control the state of the systemd system and service manager.

Targets in systemd are groups of related units that act as synchronization points during a system boot. Target unit files have a .target file extension. Target units group together various systemd units through a chain of dependencies.

For troubleshooting, you can use journalctl, which is used to query and display log messages from the systemd journal.

Starting and stopping systemd services

You can start and stop systemd services by using units which are resources. The target units are service units, which have a .service suffix. For service management tasks, you do not have to add the .service because systemd knows that you want to execute a service.

To start and stop systemd services, use the following commands:

To start a systemd service:

sudo systemctl start SERVICE

To check the status of a systemd service:

sudo systemctl status SERVICE

To stop a currently running systemd service:

sudo systemctl stop SERVICE

Stops the service and then starts it. If the service is not running, it is started.

sudo systemctl restart SERVICE

Reloads the systemd service's configuration file without interrupting operations.

systemctl reload SERVICE

Reloads the service if it supports reloading, otherwise it restarts the service. If the service is not running, it is started.

sudo systemctl reload-or-restart SERVICE

Enabling and disabling systemd services

You can enable and disable systemd services by using units which are resources.

To enable a service at boot:

sudo systemctl enable SERVICE

A symbolic link is created usually in /lib/systemd/system or etc/systemd/system pointing into the location on disk where systemdlooks for autostart files. This is either in /lib/systemd/system or /etc/systemd/system, which is usually /etc/systemd/system/EXAMPLE_TARGET.target.

For example:

sudo  systemctl enable firewalld.service
      Created symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service \u2192 /usr/lib/systemd/system/firewalld.service.
      Created symlink /etc/systemd/system/multi-user.target.wants/firewalld.service \u2192 /usr/lib/systemd/system/firewalld.service.

To disable a service from starting automatically:

sudo systemctl disable SERVICE

This removes the symbolic link that indicates that the service should be started automatically.

For example:

sudo  systemctl disable firewalld.service
      Removed /etc/systemd/system/multi-user.target.wants/firewalld.service.
      Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

To check the status of a service:

sudo systemctl status SERVICE

---

Enabling or disabling a service does not start it in the current session. You can use start or stop to start or stop the service and enable or disable it at boot, or use the --now option when enabling or disabling a service to restart the service directly.

Use case: Monitor OneDrive on Linux and synchronize changes automatically

Recently, I installed the onedrive client from abraunegg. You can look up the project here. I really like it because it is lightweight, simple, and setting it up is a piece of cake. There is just one downside. It doesn't synchronize your local OneDrive folder automatically with the cloud. That means you have to sync it up with either onedrive -s or onedrive --monitor. The second option runs an ongoing process that monitors and syncs up all changes until it is stopped. Then I got the idea to set up a simple systemd service that runs this command automatically on startup. The process is fairly simple.

First, we create the systemd service file. Because we want to run onedrive as our local user, we will use the location ~/.config/systemd/user/onedrive.service for this. If we run the service as root, the command will fail because root doesn't have OneDrive setup. There, we will create our service file like this:

[Unit]
Description=Monitor file changes in OneDrive
Documentation=https://github.com/abraunegg/onedrive
After=network-online.target

[Service]
ExecStart=/usr/bin/onedrive --monitor
Restart=on-failure
RestartSec=3

[Install]
WantedBy=default.target 

This will run the command /usr/bin/onedrive --monitor and restart every three seconds in case of failure.

Now we only have to reload systemd and enable our new service. Don't forget the --user flag this time, since we saved the service only user-wide.

systemctl --user daemon-reload
systemctl --user enable onedrive.service
systemctl --user start onedrive.service

What we can also do is check the logs of our newly created service with journalctl. Again don't forget to set the --user flag. Very important.

Conclusion

So that is it to my small introduction to systemd. Personally, I am not a huge fan of automating everything. It certainly is useful for things like CI/CD, but too much is not good either. There should be a middle ground for everything, including automation. However, when you do have to automate something, the benefits you gain in terms of efficiency and quality can greatly impact your work. One example would be automated backups. Everyone working in tech should have a basic understanding of the capabilities of tools like systemd or cronjobs to automate processes.