Segnale di passaggio a processi gestiti utilizzando supervisord

Question

Sto usando supervisord per deporre le uova e gestire un'applicazione FastCGI che sto scrivendo in C per un target Linux. Ho un gestore di segnale che esce con grazia la mia domanda quando viene ricevuto SIGINT. Ho verificato che il gestore di segnale funziona come desiderato eseguendo l'applicazione in una finestra di terminale e l'emissione Ctrl-C per uscire.

Quando un comando "shutdown" per supervisord (via supervisorctl), sembra che supervisord è in grado di forzare l'applicazione per uscire senza invocare 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)

Ho il seguente nel mio file supervisord.conf

stopsignal=INT

E 'la mia ipotesi che le questioni supervisord "stopsignal" presso l'invocazione del comando shutdown, così prendo le dichiarazioni INFO come un'indicazione del fatto che la mia applicazione non risponde al SIGINT emesso da supervisord.

Come posso fare per il debug del segnale passando tra supervisord e la mia app?

Answer 1

Dopo un po 'di più di scavo, sembra che il problema non è che supervisord non riesce a passare segnali ai processi figli. Questo sembra funzionare normalmente.

Piuttosto, sembra che supervisord interrompe la registrazione di output stderr processo figlio una volta che riceve una richiesta per invocare stopsignal. Come risultato, qualsiasi registrazione stderr basata dell'arresto processo figlio non verrà elaborato dal supervisord. Nel mio caso, questo ha reso sembrare che il processo figlio non riceveva SIGINT, dal momento che non è stato registrando nulla a stderr dopo che il segnale è stato invocato.

Answer 2

È possibile eseguire supervisord sulla riga di comando in modalità debug e ottenere ulteriori informazioni.

supervisord -n -e debug

Answer 3

Questo è stato un bug che da allora è stato risolto nel rilascio del Supervisore 3.0a10 (2011-03-30) di cui al presente commit: https://github.com/Supervisor/supervisor/commit/e19cbc185dfad045c8775750d36ab8ceed4c4dfb