Я использую оба, и они работают нормально

после обновления до версии 4.1.0 с версии 4.0.2 - вылезла аналогичная ошибка, не работает планировщик задач

То же самое и здесь, когда я отключаюсь до 4.0.2, он снова работает.

Я думаю, что эта ошибка связана с часовым поясом, когда я меняю часовой пояс на UTC, он работает.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Верно

Не могли бы вы перепроверить текущую ветку master ?

Я могу подтвердить эту ошибку в 4.1.0

в моих настройках:

CELERY_TIMEZONE = 'Europe/Moscow'

И да, он отлично работает с:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

Та же проблема - у нас есть несколько проектов с использованием сельдерея, но в одном из них CELERY_TIMEZONE был установлен в качестве часового пояса проекта, который был America / NewYork. Буквально я проснулся с 18 миллионами сообщений на сервере Rabbit QA, потому что рабочие не успевали за скоростью, которую они ставят в очередь - сотни в минуту. Удаление настроек и разрешение для проекта по умолчанию CELERY_TIMEZONE из None также решило проблему.

FWIW - Я не думаю, что мы используем DatabaseScheduler. Может, название выпуска надо переименовать?

@matteius @AyumuKasuga, если вы можете запустить тест с веткой master чтобы проверить исправление, было бы здорово. Приносим извинения за проблемы.

Привет, @georgepsarakis !
Я только что протестировал основную ветку, и, к сожалению, в моей настройке проблема все еще существует.

То же самое!

Привет,

У меня похожая проблема. Я выполнил инструкции по установке django-celery-beat из: 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'

Затем я определяю периодическую задачу:

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

При запуске взбивания сельдерея я получаю следующий результат:

$> 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...

Периодическая задача существует в базе данных и помечена как enabled .

Однако рабочий сельдерея не получает и не выполняет никаких периодических задач:

$> 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

Программное обеспечение:

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

Любые идеи / помощь в решении этой проблемы приветствуются.

Лучший,
Себастьян

Кусок дерьма. Не работает.

@ mchen-scala Я думаю, что проекты OSS предназначены для совместной, объективной и конструктивной критики. Сколько строк кода ты вложил в этот кусок дерьма? У меня на самом деле есть сельдерей с битом, работающий отлично.

Я построил гораздо более совершенные системы, чем вы когда-либо будете иметь. Я написал операционные системы и построил платформы для высокочастотной торговли и крупномасштабные БД для разных центров обработки данных. И многое другое.

Строки кода? Я смотрю только на системы, которые РАБОТАЮТ. LOC для новичков.

Мне приходится использовать сельдерей, потому что он используется в унаследованной мной системе. Я собираюсь избавиться от этого и напишу свой, как только мы закончим нашу первую доставку.

В дополнение к проблеме ритма, просить людей использовать блокировку, чтобы гарантировать, что свойство не более одного раза при выполнении задачи, является ГИГАНТНОЙ ШУТКОЙ.

Придерживайтесь того, в чем вы хороши, а именно OSS, поскольку вы не можете получить высокооплачиваемую работу.

@ mchen-scala Вы никогда в своей жизни не писали сложной системы, вы даже не можете понять контекст этого билета, который заключается в том, что в серии Celery 4 есть некоторые версии, в которых CELERY_BEAT_SCHEDULE не соблюдается, если часовой пояс отличается от UTC.

Все ваши замечания неточны и оскорбительны на многих уровнях. Шутка в том, что вы пришли сюда, чтобы оскорбить нас за работу над проектом OSS, который удовлетворяет потребности многих людей во многих отраслях. Я собираюсь предположить, что все, что вы когда-либо писали для работодателя, не получило такого внимания, как проект Celery. Поскольку вы на самом деле не ссылались ни на одну из своих предыдущих работ. В гибком мире вы будете выпускать релизы каждые 2-4 недели, поэтому тот факт, что вы работаете над унаследованным вами проектом, вместо этих потрясающих систем, которые вы предположительно построили, только указывает мне на то, что у вас завышенное чувство собственного достоинства.

Кроме того, mchen-scala, я настоятельно рекомендую вам отказаться от сельдерея - прежде всего потому, что нам не нужно ваше отношение к нашему сообществу. У меня высокооплачиваемая работа, потому что я могу использовать OSS и оказывать поддержку в устранении проблем по мере их возникновения. Я предлагаю вам следовать своей собственной мантре и придерживаться того, в чем вы хороши, что, по-видимому, заключается в том, чтобы использовать ваши собственные решения проблем с существующими решениями и быть антисоциальным придурком для остальных из нас. Ця!

Я указал точную строку кода, которая преобразует мою дату и время с указанием часового пояса в будущую дату и время со смещением +20, которое, я уверен, не является смещением реального часового пояса.
2017-10-11 22: 42: 27.041931-04: 00 преобразуется в 2017-10-12 22: 42: 27.041931 + 20:00 в строке моего запроса на слияние.
По-видимому, в режиме UTC объект datetime остается неизменным на этом этапе кода. Итак, что происходит дальше, результат «осталось_дельта» интерпретируется как -1 день, на 1: 27: 32.958069 отставание от расписания задачи. Таким образом, он отправляет задачу и не спит долго, потому что она всегда позади. Он просто продолжает выполнять задачи, потому что у него -1 день до срока выполнения задачи.

Конечно, мой PR комментирует настоящую старую строку кода, и тем не менее, все модульные тесты, казалось, прошли, и это действительно решило эту проблему в моем тестировании. Глядя на отзывы соавторов.

Я показал, что это проблема Python 2.7, а также версий Python 3.5 и 3.6. Нельзя сказать, что это не ошибка в других версиях, это просто те, с которыми я настраивал среды.

Я попытался перейти от неиспользования базы данных для удара к использованию django-celery-beat ... В тот день в основном читали проблемы с github :(

Кто-нибудь еще не заставляет это работать при использовании CELERY_TIMEZONE = 'UTC' ? У меня проблемы с тем, чтобы заставить его работать с этим набором ..

@xeor Вам также может потребоваться установить CELERY_ENABLE_UTC = True

Фактическая проблема передачи datetime в localize () заключается в том, что если для вашего проекта установлен локальный часовой пояс, а не UTC, тогда это datetime уже правильно, переходя в локализацию, а затем dt = dt.astimezone (tz) преобразует это в бессмысленное будущее datetime с бессмысленным часовым поясом.

@xeor У меня была такая же проблема даже со следующими настройками:

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

Теперь я знаю, что это кажется глупым, но я удалил и Celery, и django-celery-beat, и снова установил их с их последней версией, и это сработало.

Спасибо .. Я тоже пробовал со всеми этими тремя, но безуспешно.
Попробую позже с чистой перестройкой окружения ..

@xeor Ну, вполне возможно, что это не проблема, с которой вы столкнулись, хотя, возможно, это так. Рекомендации в этой заявке были единообразны для всех пользователей, столкнувшихся с этой проблемой до сих пор, что привело к неконтролируемому постановке в очередь запланированных задач и задачам, которые накапливались и не обрабатывались должным образом из-за этого. Не могли бы вы подробнее описать вашу конкретную проблему, поскольку не похоже, что вы оставили много деталей об ошибке (-ях) или неожиданном исходе, который вы получаете?

Всегда рады помочь. Просто отметим, что у нас была эта проблема без DatabaseScheduler, и мы исправили ее, изменив только часовые пояса. В своем тестировании я показал, что файл расписания, созданный до и после этой ошибки, был идентичен, поэтому я действительно не думаю, что ошибка связана с планировщиком, а скорее с типом времени, передаваемым в вызов localize ().

Спасибо за предупреждение!

Я не смогу сделать более глубокую петлю раньше, может быть, в конце следующей недели или через неделю. А пока я буду держать себя в курсе о прогрессе в этой теме.

Я не уверен, что моя установка является чем-то особенным, но я использую docker, amqp, rabbitmq и все новейшие версии пакетов python для сельдерея (не rabbitmq tho). (Извините, у меня нет env, поэтому я могу проверить)..

У меня аналогичная проблема, иногда сельдерей не работает (он не отправляет задачу брокеру) Кроме того, он отправляет слишком много задач каждые 59 минут
Я поставил тестовое задание запускать каждую минуту

[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)

На 59-й минуте запускается куча задач, и когда время достигает минуты 0, она снова выполняется, как ожидалось.
Я понятия не имею об этой ошибке ..?

Это моя настройка в сельдерее 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

Я использую файл db для расписания

У меня также есть эта проблема на python 3.6.3, pytz 2017.3, django 1.11.7, celery 4.1.0 и django-celery-beat 1.1.0.

Я сначала стираю базу данных:

#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)
...

И очередь продолжает заполняться со скоростью 600 / сек.

# 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 

Мои настройки (я установил все, что смог найти, потому что документация крайне неясна и устарела в нескольких местах):

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

Итак, ясно, что происходит то, что сельдерей выполняет задачу в 08: 28: 59-08, но затем, сохраняя last_run_time, он все еще добавляет 8 часов ко времени, чтобы получить 16: 28: 59-08 перед сохранением его в БД.

Беглый взгляд на schedules.py говорит мне, что мы возвращаем timedelta или # секунды из crontab.is_due ().

У меня нет больше времени, чтобы копать здесь, но очевидно, что что-то внутри класса crontab получает timedelta между текущим временем и текущим временем с его tz replaced (не преобразовано).

Я бы с большим подозрением отнесся к строкам, в которых указаны часовые пояса replace .

Хорошо - если бы каждый, у кого была эта ошибка, мог бы клонировать мастер и повторно проверить, что он устраняет проблему за вас. Мой PR был объединен прошлой ночью, и я только что подтвердил, что он исправил ошибку, но было бы неплохо получить дополнительное подтверждение для тех, кто использует планировщик БД или другие бэкенды. Спасибо!

976515108a4357397a3821332e944bb85550dfa2 примените это и проверьте