supervisord sending SIGKILL instead of SIGTERM

Question

I'm running supervisor 3.2.0-2ubuntu0.2 Ubuntu 16.04. I want to change the command that one of my processes uses, but I need to make sure that supervisor sends the correct signal to it so that the process may wrap up; unfortunately, supervisor is still sending a SIGKILL even though I've requested TERM.

[program:my-worker] process_name=%(program_name)s_%(process_num)02d command=php /home/worker/job --param=a,b,c autostart=true autorestart=true stopwaitsecs=10 user=worker stopsignal=TERM numprocs=1 stdout_logfile=/var/log/supervisor/worker.log stderr_logfile=/var/log/supervisor/worker-error.log 

If I follow Supervisor not loading new configuration files after changing the "command" (for example: php /home/worker/job --param=a,b,c,d) I get the following in the logs:

2018-08-08 09:05:21,514 INFO waiting for worker_00 to stop 2018-08-08 09:05:21,533 INFO stopped: worker_00 (terminated by (9) SIGKILL) 

I specifically need to make sure that SIGTERM is being sent - I've gone delving in to the code, but I didn't see anything obvious that would suggest my config is incorrect. Am I calling the wrong commands? service supervisord restart triggers the same.

Answer 1

supervisord sends SIGTERM to your worker, but the worker needs to intercept the signal and do the work to shut down cleanly. It then needs to send SIGCHLD back to supervisord.

If supervisord doesn't receive SIGCHLD within a certain time period, it kills the worker with SIGKILL as a last resort. See the section on stopwaitsecs here: http://supervisord.org/configuration.html

Here is an example of how to handle the signal in PHP: https://stackoverflow.com/questions/7864349/how-do-i-catch-a-kill-or-hup-or-user-abort-signal