Automatic start by using systemd: Difference between revisions
No edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
<code> | <code> | ||
#!/bin/bash | |||
# Creating message queues for operation or test of aquarium_control | |||
sudo touch /dev/mqueue/aquarium_control.5UXp | sudo touch /dev/mqueue/aquarium_control.5UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.5UXp | sudo chmod o+rwx /dev/mqueue/aquarium_control.5UXp | ||
sudo touch /dev/mqueue/aquarium_control.4UXp | sudo touch /dev/mqueue/aquarium_control.4UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.4UXp | sudo chmod o+rwx /dev/mqueue/aquarium_control.4UXp | ||
sudo touch /dev/mqueue/aquarium_control.6UXp | sudo touch /dev/mqueue/aquarium_control.6UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.6UXp | sudo chmod o+rwx /dev/mqueue/aquarium_control.6UXp | ||
sudo touch /dev/mqueue/aquarium_control.7UXp | sudo touch /dev/mqueue/aquarium_control.7UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.7UXp | sudo chmod o+rwx /dev/mqueue/aquarium_control.7UXp | ||
sudo touch /dev/mqueue/aquarium_control.8UXp | sudo touch /dev/mqueue/aquarium_control.8UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.8UXp | sudo chmod o+rwx /dev/mqueue/aquarium_control.8UXp | ||
sudo touch /dev/mqueue/aquarium_control.9UXp | sudo touch /dev/mqueue/aquarium_control.9UXp | ||
sudo chmod o+rwx /dev/mqueue/aquarium_control.9UXp | |||
sudo | # initialize lock file with 0 as PID | ||
sudo echo 0 > /var/local/aquarium-ctrl.pid | |||
# start the application to run in the background | |||
/usr/local/bin/aquarium_control > /dev/null& | /usr/local/bin/aquarium_control > /dev/null& | ||
</code> | </code> | ||
The lock file has to be initialised to zero upon restart of the server. A missing or empty lock file is interpreted by the control application that something has gone wrong and startup will be aborted. In case of uncontrolled shutdown (e.g. power failure), the PID of the last operation may still be in the lock file, hence a reset to zero is required for this case. | |||
Only one of the message queues is required for operating the control application. The other message queues are use for parallel SW unit testing. | Only one of the message queues is required for operating the control application. The other message queues are use for parallel SW unit testing. | ||
Revision as of 08:21, 4 January 2025
The content of systemd unit file /lib/systemd/system/aquarium-ctrl.service as following:
[Unit]
Description=Aquarium Control Application
After=multi-user.target
[Service]
Type=forking
ExecStart=bash /usr/local/bin/aquarium-ctrl-startup.sh
[Install]
WantedBy=multi-user.target
Upon creation/modification of the unit file, one must run the command sudo systemctl daemon-reload in order to activate the changes.
For starting the control application manually via systemd, one can use the command sudo systemctl start aquarium-ctrl.
The startup script creates a set of POSIX message queues and sets their access rights before starting the control application to run in the background.
- !/bin/bash
- Creating message queues for operation or test of aquarium_control
sudo touch /dev/mqueue/aquarium_control.5UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.5UXp
sudo touch /dev/mqueue/aquarium_control.4UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.4UXp
sudo touch /dev/mqueue/aquarium_control.6UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.6UXp
sudo touch /dev/mqueue/aquarium_control.7UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.7UXp
sudo touch /dev/mqueue/aquarium_control.8UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.8UXp
sudo touch /dev/mqueue/aquarium_control.9UXp
sudo chmod o+rwx /dev/mqueue/aquarium_control.9UXp
- initialize lock file with 0 as PID
sudo echo 0 > /var/local/aquarium-ctrl.pid
- start the application to run in the background
/usr/local/bin/aquarium_control > /dev/null&
The lock file has to be initialised to zero upon restart of the server. A missing or empty lock file is interpreted by the control application that something has gone wrong and startup will be aborted. In case of uncontrolled shutdown (e.g. power failure), the PID of the last operation may still be in the lock file, hence a reset to zero is required for this case.
Only one of the message queues is required for operating the control application. The other message queues are use for parallel SW unit testing.