Celery: Les processus de travail pré-fourchus peuvent-ils ignorer les signaux TERM ?

Créé le 4 juin 2018 · 3Commentaires · Source: celery/celery

Général

Version concernée : la plus récente (4.1.1)

Comportement prévisible

les travailleurs preforked ignorent le signal sigterm - seul le processus parent responsable de l'arrêt à chaud y réagit et arrête gracieusement les processus enfants.

Comportement actuel

Lorsque les processus de travail préforqués obtiennent un sigterm, ils s'arrêtent immédiatement (par exemple, kill <pid> ):

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

Lorsqu'un sigterm atteint le processus de travail parent, un arrêt à chaud est effectué. Si, entre-temps, les travailleurs pré-fourchus ont également reçu un signal à terme, les tâches sont simplement tuées.

Pertinence

Je ne peux pas trouver un moyen de faire un céleri d'arrêt approprié dans un conteneur docker avec un système d'initialisation.
(voir la liste de diffusion : https://groups.google.com/forum/#!topic/celery-users/9UF_VyzRt8Q). Il semble que je doive m'assurer que le terme signal n'atteint que le processus parent, mais aucun des travailleurs pré-fourchus. Cela semble être très difficile lors de l'exécution d'un script bash avec plusieurs instances de céleri (par exemple, beat et deux files d'attente)

Solution possible

Est-il possible d'ajouter une fonctionnalité qui permet aux processus de travail pré-fourchés d'ignorer le sigterm ?

Deployment Prefork Workers Pool

Source

croth1

Commentaire le plus utile

Merci @georgepsarakis et @xirdneh pour vos suggestions utiles. J'ai réussi à obtenir une configuration de travail avec superviseur ! ??
Avoir un travailleur par conteneur est également une très bonne suggestion ! Merci beaucoup!

croth1 le 4 juin 2018

🎉3

Tous les 3 commentaires

Afin d'avoir une propagation de signal appropriée lors du démarrage de plusieurs processus dans un conteneur Docker, vous avez probablement besoin d'un gestionnaire de processus tel que superviseurd .

georgepsarakis le 4 juin 2018

Pour plus d'informations, voici un aperçu de la façon dont docker arrête les choses : https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/#docker -stop

De plus, si vous utilisez déjà docker, je vous recommande de licencier un travailleur par conteneur.
C'est plus facile à gérer et les conteneurs n'ont pas beaucoup de frais généraux. Il est également plus facile d'effectuer une mise à l'échelle automatique lors de l'utilisation d'outils tels que k8s.

Une dernière chose. Si vous voulez vraiment lancer votre propre script bash pour gérer plusieurs travailleurs, vous devrez lancer chaque travailleur, puis dormir indéfiniment jusqu'à ce qu'un SIGTERM arrive .
Lorsque cela se produit, vous pouvez obtenir le PID des travailleurs, puis les arrêter gracieusement.
C'est essentiellement ce que fait Supervisord, comme l' a souligné