I've created a custom service file which looks like this:
[Unit] Description=aaa main application After=syslog.target network-online.target [Service] Type=forking PIDFile=/usr/local/aaa_path/aaa/aaa.pid WorkingDirectory=/usr/local/aaa_path/aaa/ ExecStart=/usr/local/aaa_path/aaa/run_aaa.sh Restart=always RestartSec=5 [Install] WantedBy=multi-user.target
When checking status with:
systemctl status aaa
Everything looks ok, except for:
... systemd: aaa.service: Supervising process 18285 which is not our child. We'll most likely not notice when it exits.
Wondering why this message is showing and if it is anything to be concerned about?
my ExecStart is a bash script named run_aaa.sh; What it does is prepare some environment variables, run some required maintainace scripts, and finally runs the aaa binary (as a daemon) with some dynamic command line options, in the background - and quits (the run_aaa.sh script quits, the aaa daemon binary keeps running in the background, and maintains its own pid file that systemd knows about)
I know systemd is running run_aaa.sh and expects it to fork (because I specified type=forking) and it does actually "fork" by running the "aaa" binary daemon in the background and exiting afterwards. Plus I do specify PIDFile path and my aaa binary maintains this PIDFile as it should, so why would systemd complain that it might fail to supervise my daemon?
Is there a better way to configure the service for this use case? (I must use run_aaa.sh script in order to execute my binary)