Назад | Перейти на главную страницу

супервизор, отправляющий SIGKILL вместо SIGTERM

Я использую supervisor 3.2.0-2ubuntu0.2 Ubuntu 16.04. Я хочу изменить команду, которую использует один из моих процессов, но мне нужно убедиться, что супервизор отправляет ему правильный сигнал, чтобы процесс мог завершиться; к сожалению, супервизор все еще отправляет SIGKILL, хотя я запросил 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

Если я последую Супервизор не загружает новые файлы конфигурации после изменения «команды» (например: php /home/worker/job --param=a,b,c,d) В логах получаю следующее:

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)

Мне особенно нужно убедиться, что отправляется SIGTERM - я углубился в код, но не увидел ничего очевидного, что могло бы указывать на неправильную мою конфигурацию. Я вызываю неправильные команды? service supervisord restart вызывает то же самое.

supervisord отправляет SIGTERM вашему рабочему, но рабочему необходимо перехватить сигнал и выполнить работу, чтобы завершить работу без ошибок. Затем ему необходимо отправить SIGCHLD обратно супервизору.

Если supervisord не получает SIGCHLD в течение определенного периода времени, он в крайнем случае убивает рабочего с помощью SIGKILL. См. Раздел о стопвэйтсеках здесь: http://supervisord.org/configuration.html

Вот пример того, как обрабатывать сигнал в PHP: https://stackoverflow.com/questions/7864349/how-do-i-catch-a-kill-or-hup-or-user-abort-signal