Celery: ¿Pueden los procesos de trabajo pre-bifurcados ignorar las señales TERM?

Creado en 4 jun. 2018 · 3Comentarios · Fuente: celery/celery

General

Versión afectada: última (4.1.1)

Comportamiento esperado

Los trabajadores prebifurcados ignoran la señal sigterm: solo el proceso principal responsable del apagado en caliente reacciona y apaga con gracia los procesos secundarios.

Comportamiento actual

Cuando los procesos de trabajo pre-bifurcados obtienen un sigterm, se cierran inmediatamente (por ejemplo, kill <pid> ):

celery_1        | [2018-06-04 09:19:57,376: ERROR/MainProcess] Process 'ForkPoolWorker-2' pid:26 exited with 'signal 15 (SIGTERM)'

Cuando un sigterm llega al proceso del trabajador principal, se realiza un apagado en caliente. Si, mientras tanto, los trabajadores pre-bifurcados también reciben una señal de término, las tareas simplemente se eliminan.

Relevancia

No puedo encontrar una manera de hacer un apio de apagado adecuado en un contenedor docker con un sistema de inicio.
(ver lista de correo: https://groups.google.com/forum/#!topic/celery-users/9UF_VyzRt8Q). Parece que tengo que asegurarme de que el término señal solo llegue al proceso principal, pero no a ninguno de los trabajadores prebifurcados. Esto parece ser muy difícil cuando se ejecuta un script bash con varias instancias de apio (por ejemplo, beat y dos colas)

Solución posible

¿Es posible agregar una función que permita que los procesos de trabajo pre-bifurcados ignoren el sigterm?

Deployment Prefork Workers Pool

Fuente

croth1

Comentario más útil

Gracias @georgepsarakis y @xirdneh por sus útiles sugerencias. ¡Me las arreglé para conseguir una configuración funcional con el supervisor! 🎉
¡Tener un trabajador por contenedor también es una muy buena sugerencia! ¡Muchas gracias!

croth1 en 4 jun. 2018

🎉3

Todos 3 comentarios

Para tener una propagación de señal adecuada al iniciar múltiples procesos dentro de un contenedor Docker, probablemente necesite un administrador de procesos como supervisor .

georgepsarakis en 4 jun. 2018

Para obtener más información, aquí hay una descripción general de cómo Docker detiene las cosas: https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/#docker -stop

Además, si ya está usando Docker, recomendaría despedir a un trabajador por contenedor.
Es más fácil de administrar y los contenedores no tienen tantos gastos generales. También es más fácil escalar automáticamente cuando se utilizan herramientas como k8s.

Una última cosa. Si realmente desea lanzar su propio script de bash para administrar varios trabajadores, tendrá que encender a cada trabajador y luego dormir indefinidamente hasta que aparezca un SIGTERM .
Cuando eso suceda, puede ir a buscar el PID de los trabajadores y luego detener con gracia a cada uno.
Que es básicamente lo que hace el supervisor como señaló @georgepsarakis .