JIYIK CN >

When writing web applications, I often need to offload computationally heavy tasks to an asynchronous worker script, schedule the task for later, or even write a daemon that listens on a socket to communicate directly with the client.

While there may sometimes be better tools for the job — always consider using existing software first, such as a task queue server — writing your own service gives you a level of flexibility you never get when tied to third-party software.

The cool thing is that creating a Linux service is fairly easy: write a long-running program in our favorite programming language, and then systemdturn it into a service using .

program

Let's create a small service using PHP . I can see your eyebrows rising, but it works surprisingly well. We'll listen on UDP port 10000 and return any messages received via the ROT13 transformation:

<?php

$sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_bind($sock, '0.0.0.0', 10000);

echo "server started\n";
for (;;) {
    socket_recvfrom($sock, $message, 1024, 0, $ip, $port);
    $reply = str_rot13($message);
    socket_sendto($sock, $reply, strlen($reply), 0, $ip, $port);
}

Let’s start it

$ php server.php

And test it in another terminal:

$ nc -u 127.0.0.1 10000
Hello, world!
Uryyb, jbeyq!

Cool, it works. Now we want this script to keep running, restart in case of failure (exit unexpectedly), and even survive a server reboot. This is systemdwhere <script> comes into play.

Turn it into a service

Let's create a /etc/systemd/system/rot13.servicefile called

[Unit]
Description=ROT13 demo service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=centos
ExecStart=/usr/bin/env php /path/to/server.php

[Install]
WantedBy=multi-user.target

we need to:

• User=Set your actual username after
• ExecStart=Set the correct path to the script in

That's it. We can now start the service:

$ systemctl start rot13

And automatically have it start at boot time:

$ systemctl enable rot13

Deep understanding

Now that our service is (hopefully) working, it may be important to dive into the configuration options and ensure that it continues to work as expected.

Start in the right order

We might be wondering After=what the directive does. It simply means that our service must be started after the network is ready. If the program wants the MySQL server to be up and running, it should add:

After=mysqld.service

Restart on exit

By default, systemdthe service will not be restarted if the program exits for any reason. For a service that must always be available, this is usually not what we want, so we instruct it to always restart on exit:

Restart=always

on-failureWe can also use just restart if the exit status is not 0 .

By default, systemda restart is attempted after 100 milliseconds. We can specify the number of seconds to wait before attempting a restart using:

RestartSec=1

Avoiding pitfalls: start limits

I've personally run into this situation more than once. By default, when configured like ours is Restart=always, systemd will give up on restarting our service if it starts more than 5 times within a 10 second interval. Forever.

There are two [Unit]configuration options responsible for:

StartLimitBurst=5
StartLimitIntervalSec=10

RestartSecThe directive also has an impact on the results: if it is set to restart after 3 seconds, then we will never reach 5 failed retries in 10 seconds.

A simple fix that always works is to set StartLimitIntervalSec=0. This way systemd will try to restart our service forever.

However, it is best to RestartSecset it to at least 1 second to avoid putting too much stress on the server if problems occur.

As an alternative, we can keep the default settings and require systemda server restart when the startup limit is reached, using StartLimitAction=reboot.

Is this really the case?

systemdThat's all it takes to create a Linux service using : write a small configuration file that references our long-running program.

Systemd has been the default init system in RHEL/CentOS , Fedora , Ubuntu , Debian , and others for many years, so our server is likely ready to host Homebrew services!