How to use systemd for applications start

On the latest Debian distributions is installed by default systemd instead of sysvinit as initialization system. This article illustrates pratically how to use it.

A few pieces of old way are still present and working as for example /etc/rc.local where all the applications that implement the system functionality are started.

A typical rc.local contains:

cat /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

cd /home/acmesystems
/usr/bin/nohup /usr/sbin/python myapplication.py &
exit 0

In this example a Python program is started from application's home directory, and left in background (using the trailing ampersand). That works passably well till our python application never crashes: in such unfortunate case, our system only chance has, in order to regain the lost functionality, is to be manually restarted by user (probably cycling the power...).

Usually, the quick and dirty solution suggested is to add our application to the /etc/inittab file, specifyng a respawn in the line:

id:2345:respawn:/bin/sh /path/to/application/startup

in such case startup must be a proper script able to start out application (and probably it could be convenient to reuse this script as is even in /etc/rc.local).

With systemd a different and more integrated approach is feasible. Instead of adding something to a shell script and inittable, a proper service file can be created and added to the systemd:

sudo echo > /lib/systemd/system/myapplication.service <<EOFX
[Unit]
Description=My Application as Service
After=network.target

[Service]
Type=idle
ExecStart=/usr/bin/python /home/acmesystems/myapplication.py
Restart=always
User=pi

[Install]
WantedBy=multi-user.target
EOFX

Next systemd has to be configured, enabling the service so at the next reboot it will be started automatically. First off, though, the systemd itself has to be reloaded in order to detect the new service definition:

systemctl daemon-reload

Next, enable the service

systemctl enable myapplication.service

Check if it is enabled:

systemctl list-unit-files | grep enabled

Of course, it can be started manually just now:

systemctl start myapplication.service

The PID (process id) can be now checked:

ps -ef | grep myapplication
pi         817     1  0 09:19 ?        00:00:00 /usr/bin/python myapplication.py

it is 817 (the number will be different in your case). Please note that it has been started from systemd process, in fact the PPID (parent process id) is 1.

Test what happens if the program crashes and/or terminates.

In order to simulate a crash, we kill it manually:

kill 817

Now we can check it was restarted looking again to the PID (process id):

ps -ef | grep myapplication
pi        1037     1  0 09:19 ?        00:00:00 /usr/bin/python myapplication.py

it is now 1037 (PPID always 1), so, as it is different, that means has been restarted automatically after the kill.

How to see full log from systemctl status service ?

Use the journalctl command, as in:

journalctl -u myapplication.service

Links

Andrea Montefusco
Currently employed as network architect, always Internet working man, real programmer in the past, Unix system engineer as needed, HAM Radio enthusiast (IW0HDV), aeromodeller since 1976.
http://www.montefusco.com - https://github.com/amontefusco -

The TanzoLab Project

Il TanzoLab è una iniziativa senza fini di lucro, nata da un'idea di Sergio Tanzilli socio fondatore di Acme Systems srl nel Novembre 2015, per trasferire ad appassionati di elettronica e informatica, professionisti e aziende nel settore, le conoscenze necessarie per poter creare prodotti embedded adatti per la produzione industriale.

Le attività del TanzoLab si svolgono ogni lunedi sera, salvo casi speciali, dalle ore 18:30 presso i locali della Acme Systems srl e consistono in:

  • Talk monotematici a cura di professionisti in vari settori tecnologici
  • Workshop pratici su elettronica embedded, produzione e informatica
  • Progettazione e realizzazione di nuovi prodotti embedded per l'IT

Le attività vengono coordinate tramite questo sito, in cui vengono pubblicati tutti i lavori svolti o in via di sviluppo, e tramite un gruppo Telegram con cui per interagire direttamente via chat con gli altri membri.