Celery: Redémarrage des problèmes de céleri et meilleur fichier de configuration de supervision

Les processus générés lors de la réception du signal KILL sont en effet étranges. Je ne vois pas ce comportement lorsqu'il est utilisé en dehors de supervisord , alors peut-être que c'est quelque chose qui en est la cause?

Si vous installez le module setproctitle , le céleri devrait signaler le type de processus dans les listes ps , pourriez-vous le faire pour rechercher quel type de processus est créé ?

( easy_install setproctitle )

Définir le délai d'attente sur 600 est probablement une bonne chose. Existe-t-il un réglage pour l'infini (peut-être avec un avertissement si cela prend trop de temps) ? Lorsque celeryd est tué via TERM (qui est le signal d'arrêt préféré), il arrête de recevoir des messages et attend que les tâches en cours d'exécution se terminent. Et je suppose que pour la plupart des applications, l'arrêt en cours d'exécution n'est pas acceptable.

En ce qui concerne la génération de processus : setproctitle et la surveillance des identifiants de processus ont été utiles. Ce n'est pas un processus de frai. Les processus de travail restent actifs lorsque le processus parent est tué.
Il s'agit d'une simulation de redémarrage supervisé avec élimination manuelle et délai d'attente nul :

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6101 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6108 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 nadovmeste:~# kill 6101 & kill -9 6101 &

ps-afx :

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6867 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6875 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 6108 ?        S      0:00 [celeryd.PoolWorker-1]       

Je n'ai pu reproduire cela qu'avec une telle course artificielle entre kill et kill -9 . Parfois, le travailleur est tué correctement. Le problème semble être spécifique à superviseur car lorsque je démarre celeryd à partir de la console, je n'ai aucune chance de le reproduire.

J'ai pu reproduire cela avec des scripts lancés par la console après plusieurs tentatives :

/home/nadovmeste/envs/nadovmeste/bin/python /home/nadovmeste/src/nadovmeste/manage.py celeryd -B --loglevel=INFO&

puis dans une autre session de terminal :

nadovmeste:~# ps -afx

 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash
 9343 pts/2    Sl     0:00          \_ [celeryd.MainProcess] Running... (-B --loglevel=INFO)                                                           
 9350 pts/2    S      0:00              \_ [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00              \_ [celerybeat]     

nadovmeste:~# kill 9343 & kill -9 9343

nadovmeste:~# ps -afx

 4526 ?        Ss     0:00  \_ sshd: root@pts/1 
 4529 pts/1    Ss     0:00  |   \_ -bash
 9366 pts/1    R+     0:00  |       \_ ps -afx
 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash    
 ...
 9350 pts/2    S      0:00 [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00 [celerybeat]

Je n'ai trouvé aucune option spéciale pour le délai d'attente infini avec avertissement dans la documentation de superviseur. Probablement un très grand nombre suffira si c'est ce que nous voulons.

C'est peut-être quelque chose lié à celerybeat parce que j'ai pu reproduire le problème pour celeryd démarré par la console uniquement après avoir utilisé l'option -B .

Si je teste localement certaines tâches de céleri et que j'utilise l'option -B, le processus n'est parfois pas tué lorsque j'utilise ctrl-c.

Je ne peux pas reproduire cela localement. Au fait, dirigez-vous la branche principale ? Je viens de corriger un bogue qui pouvait bloquer l'arrêt. Si vous pouviez tester avec ça, ce serait bien.

Oui, j'utilise la dernière branche master. J'ai vu votre commit de correction de bogues et j'espérais que cela aiderait, mais il semble que cela n'aide pas dans mon cas : le dernier céleri semble se comporter de la même manière. Mais il est possible que le problème initial soit résolu - je ne vérifie cela qu'avec une mise à mort immédiate. Je ne peux pas envelopper ma main autour maintenant :) Le problème ctrl-c n'est pas reproductible avec ma configuration.

Donc le rapport de bogue, simplifié : http://gist.github.com/401028 . Les résultats sont toujours les mêmes (pas parfois). J'ai des tâches périodiques et d'autres non périodiques. Les tâches sont simples et ne prennent pas beaucoup de temps à terminer. Est-ce un bogue que les processus enfants restent en vie après avoir tué le processus principal ? Si c'est le cas et que vous ne pouvez pas le reproduire, j'essaierai de fournir le projet minimal.

Le comportement de suppression de celerybeat est intéressant : lorsque je tue le processus celerybeat suspendu (?), le processus de travail suspendu (?) s'arrête également.

@kmike Je ne peux toujours pas reproduire avec les commandes ci-dessus. Peut-être parce que je suis sous OS X, ou peut-être que vous utilisez Python 2.5 ? (je suis sous 2.6.1)

Pourrait l'exécuter avec --loglevel=DEBUG? Cela pourrait fournir des informations sur l'endroit où il s'arrête.

Le processus celerybeat est démarré par le processus principal, donc je suppose que le processus principal attend
pour que le celerybeat se termine avant qu'il ne tue les processus de pool restants.

Je pensais que le processus principal avait été tué : il n'est pas visible dans la liste des processus. Je n'ai cependant pas beaucoup d'expérience en gestion de processus.

Ma configuration était Debian Lenny + python 2.5.

Je vais essayer de lancer celeryd avec --loglevel=DEBUG et de le reproduire sur mon macbook.

hum tu as raison bien sur. C'est presque comme si le processus de battement s'appropriait les processus de pool.

Je viens d'essayer de reproduire sur Debian Lenny avec python 2.5, et ça marche juste là.
J'ai essayé de tuer avec TERM et INT.

Demandez, merci de votre aide.

Je pense que le problème initial a été résolu grâce à l'augmentation du délai de supervision et à votre engagement de correction de bogues. La simulation était incorrecte car j'utilise les commandes kill -9 et elles envoient le signal KILL au lieu de TERM. Avec le signal TERM, les processus sont correctement tués.

Le superviseur utilise le signal TERM, donc tout devrait bien se passer.

Mais ce qui me fait un peu peur, c'est que le bogue initial n'a pas été étudié. Je vais essayer de le reproduire et je vous tiens au courant.

Ah ! Je suis vraiment désolé. Je n'ai pas lu le sujet assez attentivement. Oui! C'est exactement ce qui se passe lorsque vous le tuez avec SIGKILL. Le signal 9 ne peut pas être capté, donc nous ne pouvons rien faire à ce sujet AFAIK.

Si vous rencontrez toujours des problèmes pour mettre fin à vos workers Celery, vous pouvez essayer de définir stopasgroup=true avant d'augmenter votre stopwaitsecs .