Nowadays Debian distributions arrive with systemd as initialization system installed by default.
A few pieces of old sysvinit are still present (and working): one very often used is /etc/rc.local where all the applications that implement the system functionality are started.
A typical example is as follows:
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
here 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:
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:
sudo systemctl daemon-reload
Next, enable the service
sudo systemctl enable myapplication.service
Of course, it can be started manually just now:
sudo 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.
In order to simulate a crash, we kill it manually:
sudo 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.