Juste pour clarifier les choses - je travaille sur un fichier de service systemd celerybeat.service ce qui devrait régler le problème du céleri. Ce que je fais pour le moment, c'est appeler un script qui lit /var/run/celery/celerybeat.pid tue le processus avec ce PID, puis relance le processus Celery beat.
Y a-t-il un meilleur moyen d'y parvenir ?
Ce que nous faisons, c'est que nous démarrons celery comme ceci (notre application celery est dans server.py) :
python -m server --app=server multi start workername -Q queuename -c 30 --pidfile=celery.pid --beatCe qui démarre un processus celery beat avec 30 processus worker, et enregistre le pid dans celery.pid.
Ensuite, nous pouvons appeler ceci pour sortir proprement :
celery multi stop workername --pidfile=celery.pid
Je ne connaissais pas le --beat option. Je l'apprécie car maintenant je n'ai plus besoin de l'option celerybeat.service - tout sera contrôlé par le service celery.service.
Moi non plus. Ce ( metaltoad.com/blog/celery-periodic-tasks-installation-infinity ) décrivent un piège possible - "le drapeau --beat doit apparaître après worker, sinon rien ne se passera".
Pour les futurs Googlers : la documentation de celery worker --help indique que le -B o --beat doit être utilisée à des fins de développement uniquement et que vous devez démarrer celery beat séparément dans un environnement de production. Voir este pour un exemple de fichier de configuration.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
0 votes
Sur un système moderne, vous utilisez systemd, bien sûr.
0 votes
I Je suis en utilisant systemd !