How I learned to stop worrying and love systemd

I’m trying, Ringo. I’m trying real hard to be the shepherd – Jules Winnfield [Pulp Fiction, 1994]

For years there has been a community war in posts, threads, and tweets, where systemd is discredited and criticized, but is it really so bad? I don’t really know, but as a sysadmin, one of my main tasks is to manage and monitor the services on each of my servers, and in recent years most of the distros have implemented this systemd as standard.

Sysadmins reinvent ourselves constantly, and we are always researching and learning. So then, lets go to put hands-on systemd and develop new skills. Contrary to the traditional init, where the boot process is sequential, systemd uses the parallelization boot concept by creating sockets for the start of each service that needs it. In turn, this behavior allows it to interact with other daemons by abstracting those sockets and assigning their processes to control groups. The processes are then tracked using these control groups, rather than by their process IDs (PIDs), which translates into a simpler boot process and less time to start.

In systemd, services are defined in unit files with their daemons and behavior directives. The /etc/systemd/system/ directory is reserved for unit files that you create or customize.

To create a service, you must create it with the form: <unit_name>.<service>.

This unit file starts the script indicated in the ExecStart option with the <user> set with User. If the script fails or stops, an attempt will be made to restart as indicated in the Restart option. The StandardOutput and StandardError options ensure that the script’s standard and error output will be written to the systemd log.

In my most recent experience, as an example of real-life, day-to-day, I had a server with a small web service running inside a container (yes, I know, but you know the customers). To optimize and automate the service, I created a systemd unit file for a Podman container to allows users to control the lifecycle of the container through systemctl.

After copying the unit file to /etc/systemd/system/myhttpservice.service, reload the systemd manager configuration with the command: systemctl daemon-reload. Then, you can handle the container as a systemd-managed service:

# systemctl start myhttpservice.service ← to start the container
# systemctl status myhttpservice.service ← to check the container service status
# systemctl start myhttpservice.service ← to stop the container

The container’s functionality is not affected when being managed by systemd. You can even use Podman commands to monitor the health of the container:

[root@server ~]# podman healthcheck run myhttpservice
healthy

So don’t worry. Systemd can help you, just trust it. If you want to know more:

• RHEL7 systemd Basics
• Demystifying systemd
• systemd Cheat Sheet for Red Hat Enterprise Linux 7
• Intro to Podman
• Monitoring container vitality and availability with Podman
• How can I control podman containers through systemd?

I hope this information helps you.