Сигнал, проходящий к управляемым процессам, используя супервизор
-
30-09-2019 - |
Вопрос
Я использую Supervisord, чтобы создать и управлять приложением FastCGI, которое я пишу в C для цели Linux. У меня есть обработчик сигнала, который изящно выходит из моего приложения при получении Сигинта. Я проверил, что обработчик сигнала работает по желанию, запустив приложение в окне терминала и выпуску CTRL-C для выхода.
При выдаче команды «отключение» на Superisisord (через Supervisorctl), похоже, что руководитель не может заставить приложение выйти, не вызывая SIGKILL:
2010-08-20 10:02:49,661 INFO waiting for cse to die
2010-08-20 10:02:52,665 INFO waiting for cse to die
2010-08-20 10:02:55,669 INFO waiting for cse to die
2010-08-20 10:02:58,672 INFO waiting for cse to die
2010-08-20 10:02:59,673 WARN killing 'cse' (2031) with SIGKILL
2010-08-20 10:02:59,674 INFO stopped: cse (terminated by SIGKILL)
У меня есть следующее в моем файле Supervisord.conf.
stopsignal=INT
Это мое предположение о том, что руководитель вызывает «stocksignal» при вызове командования выключения, поэтому я беру информационные операторы в качестве указания, что мое приложение не отвечает на Сигинт, выданный руководством.
Как мне пойти в отладку сигнала, проходящего между руководством и моим приложением?
Решение 2
После некоторого количества копания представляется, что проблема не в том, что руководитель не может проходить сигналы до дочерних процессов. Это, кажется, работает нормально.
Скорее, кажется, что руководитель переходит в систему регистрации ребенка STDERR выходов после того, как он получает запрос, чтобы вызвать stopsignal. В результате любая нажатие на основе STDERR, основанное на выключении ребенка, не будет обработана руководством. В моем случае это сделало это, по-видимому, дочерний процесс не получал SIGINT, поскольку он не ввел что-нибудь для STDERR после того, как сигнал был вызван.
Другие советы
Вы можете запустить руководителя в командной строке в режиме отладки и получить дополнительную информацию.
Supervisord -n -e Debug
Это была ошибка, которая с тех пор была зафиксирована в выпуске 3.0A10 (2011-03-30) Supervisor согласно этому комми. https://github.com/supervisor/supervisor/commit/e19cbc185dfad045c8775750d36ab8975750d36ab8emast4c4dfb.