Celery: Können vorverzweigte Worker-Prozesse TERM-Signale ignorieren?

Erstellt am 4. Juni 2018 · 3Kommentare · Quelle: celery/celery

Allgemein

Betroffene Version: neueste (4.1.1)

Erwartetes Verhalten

Preforked-Worker ignorieren das Sigterm-Signal - nur der für das Warm-Shutdown verantwortliche übergeordnete Prozess reagiert darauf und fährt die untergeordneten Prozesse ordnungsgemäß herunter.

Aktuelles Verhalten

Wenn vorverzweigte Worker-Prozesse ein Sigterm erhalten, werden sie sofort heruntergefahren (z. B. kill <pid> ):

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

Wenn ein Sigterm den übergeordneten Worker-Prozess erreicht, wird ein Warm-Shutdown durchgeführt. Wenn zwischenzeitlich auch die vorgegabelten Arbeiter ein Begriffssignal bekommen, werden die Aufgaben einfach getötet.

Relevanz

Ich kann keinen Weg finden, einen ordnungsgemäßen Shutdown-Sellerie in einem Docker-Container mit einem Init-System durchzuführen.
(siehe Mailingliste: https://groups.google.com/forum/#!topic/celery-users/9UF_VyzRt8Q). Es scheint, dass ich darauf achten muss, dass der Begriff Signal nur den übergeordneten Prozess erreicht, nicht jedoch einen der vorverzweigten Arbeiter. Dies scheint sehr schwierig zu sein, wenn ein Bash-Skript mit mehreren Sellerie-Instanzen ausgeführt wird (z. B. Beat und zwei Warteschlangen).

Mögliche Lösung

Ist es möglich, eine Funktion hinzuzufügen, die es erlaubt, dass Prefork-Worker-Prozesse das Sigterm ignorieren?

Deployment Prefork Workers Pool

Quelle

croth1

Hilfreichster Kommentar

Danke @georgepsarakis und @xirdneh für deine hilfreichen Vorschläge. Ich habe es geschafft, mit Supervisord ein funktionierendes Setup zu bekommen! 🎉
Ein Arbeiter pro Container ist auch ein sehr guter Vorschlag! Danke vielmals!

croth1 am 4. Juni 2018

🎉3

Alle 3 Kommentare

Um beim Starten mehrerer Prozesse in einem Docker-Container eine ordnungsgemäße Signalausbreitung zu erzielen, benötigen Sie wahrscheinlich einen Prozessmanager wie Supervisord .

georgepsarakis am 4. Juni 2018

Für weitere Informationen finden Sie hier eine Übersicht darüber, wie Docker Dinge stoppt: https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/#docker -stop

Wenn Sie Docker bereits verwenden, würde ich empfehlen, einen Arbeiter pro Container zu entlassen.
Es ist einfacher zu verwalten und Container haben nicht so viel Overhead. Auch die automatische Skalierung ist einfacher, wenn Tools wie k8s verwendet werden.

Eine letzte Sache. Wenn Sie wirklich Ihr eigenes Bash-Skript erstellen möchten, um mehrere Worker zu verwalten, müssten Sie jeden Worker hochfahren und dann auf
Wenn das passiert, können Sie die Arbeiter-PID holen und dann jeden einzelnen anmutig stoppen.
Was im Grunde das ist, was Supervisord tut, wie @georgepsarakis betonte.

xirdneh am 4. Juni 2018