J'utilise les deux et ils fonctionnent très bien

après la mise à jour vers la version 4.1.0 à partir de la version 4.0.2 - a obtenu une erreur similaire, le planificateur de tâches ne fonctionne pas correctement

idem ici, lorsque je passe à la version 4.0.2, cela fonctionne à nouveau.

Je pense que ce bug est lié au fuseau horaire, lorsque je change le fuseau horaire en UTC, cela fonctionne.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Vrai

Pourriez-vous vérifier à nouveau avec la branche master ?

Je peux confirmer ce bug dans 4.1.0

dans mes paramètres :

CELERY_TIMEZONE = 'Europe/Moscow'

Et oui ça marche bien avec :

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

Même problème : nous avons plusieurs projets utilisant le rythme du céleri, mais l'un d'entre eux a défini CELERY_TIMEZONE comme fuseau horaire du projet, à savoir America/NewYork. Littéralement, je me suis réveillé avec 18 millions de messages sur le serveur Rabbit QA parce que les travailleurs ne pouvaient pas suivre le rythme auquel ils sont mis en file d'attente - des centaines par minute. Supprimer les paramètres et laisser le projet par défaut à CELERY_TIMEZONE sur Aucun a également résolu le problème.

FWIW -- Je ne pense pas que nous utilisions le DatabaseScheduler. Peut-être faudrait-il renommer le nom du problème ?

@matteius @AyumuKasuga si vous pouvez exécuter un test avec la branche master pour vérifier le correctif, ce serait formidable. Désolé pour les problèmes.

Bonjour @georgepsarakis !
Je viens de tester la branche master et malheureusement, dans ma configuration, le problème persiste.

Pareil ici!

Salut,

J'ai le même problème. J'ai suivi les instructions d'installation de django-celery-beat de : http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_RESULT_BACKEND = 'django-db'
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

Ensuite, je définis une tâche périodique :

@periodic_task(run_every=timedelta(seconds=30))
def do_stuff():
   print("HI")

Au démarrage du battement de céleri, j'obtiens le résultat suivant :

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj beat -l info
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-08-28 15:58:44
Configuration ->
    . broker -> amqp://guest:**<strong i="14">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%INFO
    . maxinterval -> 5.00 seconds (5s)
[2017-08-28 15:58:44,425: INFO/MainProcess] Writing entries...
[2017-08-28 15:58:45,629: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-08-28 15:58:45,630: INFO/MainProcess] Writing entries...

La tâche périodique existe dans la base de données et est marquée comme enabled .

Cependant, un travailleur du céleri ne reçoit ni n'exécute de tâches périodiques :

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj worker -l info -E

 -------------- celery@proj-dev v4.0.2 (latentcall)
---- **** ----- 
--- * ***  * -- Linux-4.4.0-83-generic-x86_64-with-Ubuntu-16.04-xenial 2017-08-28 15:57:42
-- * - **** --- 
- ** ---------- [config]
- ** ---------- .> app:         proj:0x7f89f78faeb8
- ** ---------- .> transport:   amqp://guest:**<strong i="20">@localhost</strong>:5672//
- ** ---------- .> results:     
- *** --- * --- .> concurrency: 1 (prefork)
-- ******* ---- .> task events: ON
--- ***** ----- 
 -------------- [queues]
                .> celery           exchange=celery(direct) key=celery


[tasks]
  . proj.tasks.do_nothgin
  . proj.tasks.do_stuff

[2017-08-28 15:57:42,269: INFO/MainProcess] Connected to amqp://guest:**@127.0.0.1:5672//
[2017-08-28 15:57:42,287: INFO/MainProcess] mingle: searching for neighbors
[2017-08-28 15:57:43,324: INFO/MainProcess] mingle: all alone

Logiciel:

celery==4.1.0
django-celery-beat==1.0.1
django-celery-results==1.0.1
Django==1.8.2

Toute idée/aide pour résoudre ce problème est la bienvenue.

Meilleur,
Sébastien

Un morceau de merde. Cela ne fonctionne pas.

@mchen-scala Je pense que les projets OSS sont destinés aux critiques collaboratifs et objectifs et constructifs. Combien de lignes de codes as-tu mis dans la merde ? En fait, j'ai du céleri avec beat qui fonctionne parfaitement.

J'ai construit des systèmes bien plus avancés que vous n'en aurez jamais. J'ai écrit des systèmes d'exploitation et construit des plateformes de trading à haute fréquence et des bases de données inter-centres de données à grande échelle. Et beaucoup plus.

Des lignes de code ? Je ne regarde que les systèmes qui FONCTIONNENT. LOC est pour les tyros.

Je dois utiliser Celery car le système dont j'ai hérité l'utilise. Je vais m'en débarrasser et écrire le mien une fois que nous aurons terminé notre première livraison.

En plus du problème de battement, demander aux gens d'utiliser un verrou pour garantir la propriété au plus une fois dans l'exécution de la tâche est une GIGANTESQUE JOKE.

Tenez-vous-en à ce pour quoi vous êtes bon, à savoir les logiciels libres, car vous ne pouvez pas obtenir d'emplois bien rémunérés.

@mchen-scala Vous n'avez jamais écrit de système complexe de votre vie, vous ne pouvez même pas comprendre le contexte de ce ticket, à savoir que dans la série Celery 4, il existe des versions où le CELERY_BEAT_SCHEDULE n'est pas suivi si le fuseau horaire n'est pas UTC.

Vos points sont tous inexacts et insultants à plusieurs niveaux. La blague, c'est que vous venez ici pour nous insulter de travailler sur un projet OSS qui répond aux besoins de nombreuses personnes dans de nombreuses industries. Je vais supposer que tout ce que vous avez écrit pour un employeur n'a pas vu le jour autant que le projet Celery. Comme vous n'avez fait référence à aucun de vos travaux antérieurs. Dans un monde agile, vous sortiriez toutes les 2 à 4 semaines, donc le fait que vous travailliez sur un projet dont vous avez hérité au lieu de ces systèmes impressionnants que vous êtes censés avoir construits ne fait qu'indiquer pour moi que vous avez une estime de vous-même gonflée.

De plus, mchen-scala, je vous encourage à éteindre le céleri, principalement parce que nous n'avons pas besoin de vos attitudes dans notre communauté. J'ai un travail bien rémunéré car je suis capable de tirer parti des logiciels libres et de fournir une assistance pour résoudre les problèmes au fur et à mesure qu'ils surviennent. Je vous suggère de suivre votre propre mantra et de vous en tenir à ce pour quoi vous êtes bon, qui apparemment consiste à proposer vos propres solutions aux problèmes avec les solutions existantes, et à être un imbécile antisocial pour le reste d'entre nous. Cia !

J'ai localisé la ligne de code exacte qui convertit ma datetime déjà consciente du fuseau horaire en une datetime future dans un décalage +20 qui, j'en suis sûr, n'est pas un décalage horaire réel.
2017-10-11 22:42:27.041931-04:00 est converti en 2017-10-12 22:42:27.041931+20:00 à la ligne de ma Pull Request.
Apparemment, en mode UTC, l'objet datetime reste le même à ce stade du code. Donc, ce qui se passe ensuite, c'est que le résultat de restant_delta est interprété comme étant -1 jour, 1:27:32.958069 en retard sur le calendrier des tâches. Il envoie donc la tâche et ne dort pas longtemps car il est toujours en retard. Il continue de battre les tâches, toujours parce qu'il est de -1 jours jusqu'à ce que la tâche soit due.

Certes, mon PR commente une vraie vieille ligne de code, et pourtant tous les tests unitaires semblaient réussir et cela a résolu ce problème lors de mes tests. À la recherche des commentaires des collaborateurs.

J'ai montré qu'il s'agissait d'un problème sur Python 2.7 ainsi que sur les versions Python 3.5 et 3.6. Cela ne veut pas dire que ce n'est pas un bogue dans d'autres versions, ce ne sont que celles avec lesquelles j'ai configuré des environnements.

J'ai essayé de migrer de ne pas utiliser la base de données pour beat à l'utilisation de django-celery-beat... La journée a été principalement consacrée à la lecture des problèmes de github :(

Y a-t-il quelqu'un d'autre qui ne fonctionne pas lors de l'utilisation de CELERY_TIMEZONE = 'UTC' ? J'ai également du mal à le faire fonctionner avec cet ensemble.

@xeor Vous devrez peut-être également définir CELERY_ENABLE_UTC = True

Le problème réel de la datetime transmise à localize() est que si vous avez défini un fuseau horaire local et non UTC pour votre projet, alors cette datetime est déjà correcte pour localiser, puis dt = dt.astimezone(tz) le transforme en un datetime future non-absurde avec un fuseau horaire qui n'a aucun sens.

@xeor j'avais le même problème même avec les paramètres suivants:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

Maintenant, je sais que cela semble idiot, mais j'ai désinstallé à la fois Celery et django-celery-beat, et les ai réinstallés avec leur dernière version et cela a fonctionné.

Merci .. J'ai essayé avec tous ces 3 aussi, sans chance.
Je l'essayerai plus tard avec une reconstruction propre de l'environnement.

@xeor Eh bien, il est très possible que ce problème ne soit pas le problème que vous rencontrez, même si c'est peut-être le cas. Les conseils contenus dans ce ticket ont été cohérents pour tous les utilisateurs ayant rencontré ce problème jusqu'à présent, ce qui a entraîné une mise en file d'attente incontrôlable des tâches planifiées et de celles qui s'accumulent et ne sont pas traitées correctement à cause de cela. Pourriez-vous décrire plus précisément votre problème car il ne semble pas que vous ayez laissé beaucoup de détails sur l'erreur ou le résultat inattendu que vous obtenez ?

Toujours heureux d'aider. Juste en notant que nous avons eu ce problème sans DatabaseScheduler et que nous l'avons résolu en modifiant uniquement les fuseaux horaires. Lors de mes tests, j'ai montré que le fichier de planification généré avant et après ce bogue était identique, donc je ne pense vraiment pas que le bogue concerne le planificateur, mais plutôt le type de date et d'heure transmis à l'appel localize().

Merci pour l'information!

Je ne pourrai pas faire une boucle plus profonde avant peut-être la fin de la semaine prochaine ou la semaine d'après. Je me tiendrai au courant de l'évolution de ce fil en attendant.

Je ne sais pas si ma configuration est spéciale, mais j'utilise docker, amqp, rabbitmq et toutes les versions les plus récentes des packages céleri python (pas rabbitmq tho) .. (désolé, je n'ai pas l'env ici, donc je peut vérifier)..

J'ai un problème similaire, parfois celery-beat ne fonctionne pas (il n'envoie pas de tâche au courtier) De plus, il envoie trop de tâches toutes les 59 minutes
J'ai fait une tâche de test à exécuter toutes les minutes

[2017-11-09 20:52:00,052: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:53:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:54:00,019: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:55:00,027: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:56:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:57:00,004: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:58:00,045: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,032: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,035: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,037: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,044: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
...
[2017-11-09 20:59:59,977: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,979: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,981: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,986: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,989: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,994: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,997: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:00:00,000: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:01:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:02:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:03:00,053: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)

À la minute 59, un tas de tâches commence à s'exécuter et lorsque le temps atteint la minute 0, il s'exécute à nouveau comme prévu.
Je n'ai aucune idée de ce bug..?

Ceci est mon réglage dans le céleri 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

J'utilise le fichier db pour le calendrier

J'ai également ce problème sur python 3.6.3, pytz 2017.3, django 1.11.7, celery 4.1.0 et django-celery-beat 1.1.0.

J'efface d'abord la base de données :

#update django_celery_beat_periodictask set last_run_at = NULL;
#select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
celery.backend_cleanup |                                                       

> pipenv run celery beat -A appname -l debug --scheduler django_celery_beat.schedulers:DatabaseScheduler
Loading .env environment variables…
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-11-30 08:28:58
Configuration ->
    . broker -> amqp://guest:**<strong i="9">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%DEBUG
    . maxinterval -> 5.00 seconds (5s)
[2017-11-30 08:28:58,945: DEBUG/MainProcess] Setting default socket timeout to 30
[2017-11-30 08:28:58,946: INFO/MainProcess] beat: Starting...
[2017-11-30 08:28:58,946: DEBUG/MainProcess] DatabaseScheduler: initial read
[2017-11-30 08:28:58,946: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:58,968: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,068: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,115: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-11-30 08:28:59,115: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,115: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,121: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,122: DEBUG/MainProcess] beat: Ticking with max interval->5.00 seconds
[2017-11-30 08:28:59,138: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'capabilities': {'publisher_confirms': True, 'exchange_exchange_bindings': True, 'basic.nack': True, 'consumer_cancel_notify': True, 'connection.blocked': True, 'consumer_priorities': True, 'authentication_failure_close': True, 'per_consumer_qos': True, 'direct_reply_to': True}, 'cluster_name': 'rabbit<strong i="10">@Jupiter</strong>', 'copyright': 'Copyright (C) 2007-2017 Pivotal Software, Inc.', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'platform': 'Erlang/OTP 20.1', 'product': 'RabbitMQ', 'version': '3.6.14'}, mechanisms: [b'AMQPLAIN', b'PLAIN'], locales: ['en_US']
[2017-11-30 08:28:59,152: DEBUG/MainProcess] using channel_id: 1
[2017-11-30 08:28:59,153: DEBUG/MainProcess] Channel open
[2017-11-30 08:28:59,154: DEBUG/MainProcess] beat: Synchronizing schedule...
[2017-11-30 08:28:59,155: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,160: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,161: DEBUG/MainProcess] celery.backend_cleanup sent. id->1dd626be-1dea-43ec-b000-ab61fdd33f9d
[2017-11-30 08:28:59,163: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,163: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a9c7d44-e570-4a5a-9803-0a8e5111f035
[2017-11-30 08:28:59,165: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,166: DEBUG/MainProcess] celery.backend_cleanup sent. id->114ee8e1-4b3c-4f43-a632-9a249d7db364
[2017-11-30 08:28:59,167: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,168: DEBUG/MainProcess] celery.backend_cleanup sent. id->5b7f3825-d6c8-43a5-b056-2d567ec2c4df
[2017-11-30 08:28:59,170: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,171: DEBUG/MainProcess] celery.backend_cleanup sent. id->f1bfb936-0dd1-47b6-be10-3763d4446758
[2017-11-30 08:28:59,172: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,173: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a12f2da-3717-45ab-b018-6b4fd7b83982
[2017-11-30 08:28:59,175: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,175: DEBUG/MainProcess] celery.backend_cleanup sent. id->64fbd61d-e80e-4a32-a49d-31ddc7e155c7
[2017-11-30 08:28:59,177: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,179: DEBUG/MainProcess] celery.backend_cleanup sent. id->ff38e88e-e7e8-4436-9724-9c416dde4d72
[2017-11-30 08:28:59,181: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,181: DEBUG/MainProcess] celery.backend_cleanup sent. id->d5116c47-df14-4f3e-a4d1-09087cd1af80
[2017-11-30 08:28:59,183: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
...

Et la file d'attente continue de se remplir au rythme de 600/sec.

# select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
 celery.backend_cleanup   | 2017-11-30 16:40:59.352453-08 

Mes paramètres sont (j'ai mis tout ce que j'ai pu trouver car la documentation est extrêmement peu claire et obsolète à plusieurs endroits) :

settings.py
CELERY_TIMEZONE = 'Canada/Pacific'
CELERY_ENABLE_UTC=False
USE_TZ = True
TIME_ZONE = 'Canada/Pacific'

celery.py
app = Celery('MyApp')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.conf.timezone = 'Canada/Pacific'
app.conf.enable_utc = False

Il est donc clair que ce qui se passe est que le céleri exécute la tâche à 08:28:59-08, mais lors du stockage du last_run_time, il ajoute encore 8 heures au temps pour obtenir 16:28:59-08 avant de le stocker dans la BD.

Un rapide coup d'œil à schedules.py me dit que nous retournons un timedelta ou # secondes de crontab.is_due().

Je n'ai pas plus de temps pour continuer à creuser ici, mais il est évident que quelque chose dans la classe crontab obtient un timedelta entre l'heure actuelle et l'heure actuelle avec son tz replaced (non converti).

Je serais très méfiant des lignes qui replace fuseaux horaires.

D'accord -- Si tous ceux qui ont eu ce bogue pouvaient cloner le maître et re-tester qu'il résout le problème pour vous. Mon PR a été fusionné hier soir et je viens de vérifier qu'il corrige le bogue, mais il serait bon d'en obtenir une confirmation supplémentaire pour ceux qui utilisent le planificateur DB ou d'autres backends. Merci!

976515108a4357397a3821332e944bb85550dfa2 appliquer ceci et vérifier