Signal passant aux processus gérés en utilisant supervisord

Question

J'utilise supervisord pour frayer et gérer une application FastCGI que je vous écris en C pour une cible de Linux. J'ai un gestionnaire de signal qui sort grâce ma demande quand SIGINT est reçu. J'ai vérifié que le gestionnaire de signal fonctionne comme souhaité par l'exécution de l'application dans un terminal d'émission et Ctrl-C à la sortie.

Lors de l'émission d'une commande « d'arrêt » de supervisord (via supervisorctl), il apparaît que supervisord est incapable de forcer l'application à la sortie sans invoquer 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)

Je suit dans mon fichier supervisord.conf

stopsignal=INT

Je présume que les questions supervisord « stopsignal » à l'invocation de la commande d'arrêt, alors je prends les déclarations INFO comme une indication que mon application ne répond pas à l'SIGINT émis par supervisord.

Comment puis-je sur le débogage du signal qui passe entre supervisord et mon application?

Answer 1

Après un peu plus creuser, il semble que la question n'est pas supervisord ne parvient pas à passer des signaux aux processus enfants. Cela semble fonctionner normalement.

Au contraire, il semble que supervisord arrête d'enregistrer la sortie de processus enfant stderr une fois qu'il reçoit une demande d'invoquer stopsignal. En conséquence, toute exploitation forestière basée stderr-de l'arrêt du processus de l'enfant ne sera pas traitée par supervisord. Dans mon cas, cela fait apparaître que le processus de l'enfant ne recevait pas SIGINT, car il n'a pas été tout à stderr après l'exploitation forestière du signal a été invoqué.

Answer 2

Vous pouvez exécuter supervisord sur la ligne de commande en mode débogage et obtenir plus d'informations.

supervisord -n -e debug

Answer 3

Ce fut un bug qui a été corrigé depuis la libération du superviseur 3.0a10 (2011-03-30) selon ce commit: https://github.com/Supervisor/supervisor/commit/e19cbc185dfad045c8775750d36ab8ceed4c4dfb