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.

Patrick Tinsley · Answer

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

supervisord sending SIGKILL instead of SIGTERM

One Answer

Add your own answers!

Ask a Question