Skip to main content

How I learned to stop worrying and love systemd

A personal journey of systemd discovery, from services and even containers.
Image
Stop worrying and love systemd
"No Stopping Love" by cogdogblog 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.

Image
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>.

Image
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.

Image
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
healthy

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 Senior Technical Support Engineer of Red Hat, based in Mexico City and an Enable SysAdmin contributor. With more than 10 years of experience as SysAdmin, he has strong expertise on Infrastructure Hardening and Automation. More about me

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX