0

I have a systemd service called sitesdb-job-runner.service with the following config:

[Unit]
Description=SitesDB Background Job Runner
After=network.target mariadb.service

[Service]
Type=simple
Restart=always
User=sitesdb
ExecStart=/bin/scl enable rh-git29 rh-php71 "/var/www/sitesdb/current/bin/console --env=prod jms-job-queue:run -v"

[Install]
WantedBy=multi-user.target

When I run systemctl stop sitesdb-job-runner, a SIGTERM is not sent to my process. I know this because the process logs when it receives a SIGTERM so it can gracefully shut down.

After some investigation, I suspect this is related to the scl wrapper I'm using to actually execute the script. When I run /bin/scl enable rh-git29 rh-php71 "/var/www/sitesdb/current/bin/console --env=prod jms-job-queue:run -v" directly, I get these three processes spawned:

(1) /bin/scl enable rh-git29 rh-php71 /var/www/sitesdb/current/bin/console --env=prod jms-job-queue:run
(2) /bin/bash /var/tmp/sclSdT0wu
(3) php /var/www/sitesdb/current/bin/console --env=prod jms-job-queue:run -v

If I manually target the PID of the third process (my actual command) and sent it a SIGTERM, it works as expected. But when I sent a SIGTERM to the parent process, my process does not get the SIGTERM.

My understanding of the default behavior of systemd is that it will send a SIGTERM to all processes and child processes, but I guess something else is going on here.

Any ideas?

Brian
  • 240
  • 3
  • 16
  • Does the `/bin/scl enable` process stay alive for the entire runtime of the service? If not, systemd might think your service is already stopped. You should use `Type=forking` in that case. – Lucas Werkmeister Oct 14 '18 at 10:16
  • Yes it stays alive. When I run `systemctl status sitesdb-job-runner` it provides an accurate status that it is running. – Brian Oct 14 '18 at 14:17

0 Answers0