Skip to main content

How I learned to stop worrying and love systemd

A personal journey of systemd discovery, from services and even containers.

No Stopping Love by Alan Levine is licensed under CC0 1.0

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.

Systemd parallelized daemon 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>.

Creating a new systemd 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.

systemd unit file for a podman container

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

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

I hope this information helps you.

Topics:   Linux  
Author’s photo

Alex Callejas

Alex Callejas is a Services Content Architect of Red Hat, based in Mexico City and an Enable Sysadmin contributor. With more than 20 years of experience as Sysadmin, he has strong expertise on infrastructure hardening and automation. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.