Señal que pasa a procesos gestionados mediante supervisord

StackOverflow https://stackoverflow.com/questions/3533371

Pregunta

Estoy utilizando supervisord para desovar y gestionar una aplicación FastCGI que estoy escribiendo en C para un objetivo Linux. Tengo un controlador de señal que sale de mi solicitud con gracia cuando se recibe SIGINT. He comprobado que el manejador de señal funciona como se desea mediante la ejecución de la aplicación en una ventana de terminal y la emisión de Ctrl-C para salir.

Cuando se emite un comando de "apagado" a supervisord (a través de supervisorctl), parece que supervisord es incapaz de forzar la aplicación para salir sin invocar 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)

Tengo el siguiente en mi archivo supervisord.conf 

stopsignal=INT

Es mi suposición de que las cuestiones supervisord "stopsignal" en la invocación del comando de apagado, así que tomo las declaraciones INFO como una indicación de que mi aplicación no responde a la SIGINT emitido por supervisord.

¿Cómo hago para la depuración de la señal que pasa entre supervisord y mi aplicación?

¿Fue útil?

Solución 2

Después de un poco más de excavación, parece que el problema no es que supervisord está fallando para pasar señales a procesos secundarios. Esto parece estar funcionando normalmente.

Más bien, parece que supervisord detiene el registro de salida stderr proceso hijo una vez que se recibe una solicitud para stopsignal invoke. Como resultado, cualquier registro basado en stderr de la suspensión de proceso hijo no será procesada por supervisord. En mi caso, esto hace que parezca que el proceso hijo no estaba recibiendo SIGINT, ya que no estaba registrando nada en stderr después de que se invoca la señal.

Otros consejos

Puede ejecutar supervisord en la línea de comandos en modo de depuración y obtener más información.

supervisord -n -e depuración

Este fue un error que desde entonces ha sido fijado en la liberación de Supervisor 3.0a10 (2011-03-30) según esta cometer: https://github.com/Supervisor/supervisor/commit/e19cbc185dfad045c8775750d36ab8ceed4c4dfb

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top