我正在使用两者，它们工作得很好

从 4.0.2 版更新到 4.1.0 版后 - 出现类似错误，任务调度程序无法正常工作

同样在这里，当我降级到 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 beat 的项目，但其中一个碰巧将 CELERY_TIMEZONE 设置为美国/纽约的项目时区。 我醒来时发现 Rabbit QA 服务器中有 1800 万条消息，因为工作人员无法跟上他们排队的速度——每分钟数百条。 删除设置并让项目默认为 None 的 CELERY_TIMEZONE 也解决了这个问题。

FWIW——我认为我们没有使用 DatabaseScheduler。 也许问题名称应该重命名？

@matteius @AyumuKasuga如果您可以使用master分支运行测试来验证修复程序，那就太好了。 很抱歉这些问题。

你好@georgepsarakis ！
我刚刚测试了 master 分支，不幸的是在我的设置中问题仍然存在。

同样在这里！

你好，

我有一个类似的问题。 我按照以下 django-celery-beat 设置说明进行操作： http :

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

开始 celery beat 时，我得到以下输出：

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

但是，celery worker 不会接收或执行任何周期性任务：

$> 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 项目是为了协作、客观和建设性的批评者。 你在狗屎里放了多少行代码？ 我实际上有与节拍完美配合的芹菜。

我已经建立了比你所拥有的更先进的系统。 写过操作系统，搭建过高频交易平台和大型跨数据中心DB。 还有很多。

代码行数？ 我只看有效的系统。 LOC 是给 tyros 的。

我必须使用 Celery，因为我继承的系统使用它。 一旦我们完成我们的第一次交付，我将摆脱它并写我自己的。

除了 beat 问题之外，要求人们使用锁来确保任务执行中的最多一次属性是一个巨大的笑话。

坚持你擅长的，这就是OSS，因为你找不到高薪工作。

@mchen-scala 你从来没有写过一个复杂的系统，你甚至无法理解这张票的上下文，那就是在 Celery 4 系列中有一些版本，如果时区不是 UTC，则不遵循 CELERY_BEAT_SCHEDULE。

你的观点在很多层面上都是不准确的和侮辱性的。 开玩笑的是，你来这里是为了侮辱我们从事一个 OSS 项目，该项目满足了许多行业的许多人的需求。 我将假设你为雇主写的任何东西都没有像 Celery 项目那样大放异彩。 因为您实际上没有参考您以前的任何作品。 在敏捷世界中，您将每 2 到 4 周发布一次，因此，您正在开发一个您继承的项目，而不是您应该构建的这些很棒的系统，这一事实仅向我表明，您对自我价值有一种膨胀的感觉。

此外，mchen-scala，我确实鼓励你关掉芹菜——主要是因为我们不需要你在我们的社区中的态度。 我有一份高薪工作，因为我能够利用 OSS 并在出现问题时提供支持以解决问题。 我建议你遵循你自己的口头禅并坚持你擅长的事情，这显然是用你自己的解决方案来解决现有解决方案的问题，并对我们其他人来说是一个反社会的混蛋。 青！

我已经指出了将我已经知道时区的日期时间转换为偏移量 +20 中的未来日期时间的确切代码行，我确信这不是真正的时区偏移量。
2017-10-11 22:42:27.041931-04:00 在我的 Pull Request 中被转换为 2017-10-12 22:42:27.041931+20:00。
显然，在 UTC 模式下，日期时间对象在代码中的这一点保持不变。 那么接下来发生的事情是将剩余_delta 的结果解释为 -1 天，比任务计划晚 1:27:32.958069。 所以它发出任务并且不会长时间休眠，因为它总是落后。 它只是不断地完成任务，总是因为在任务到期之前它是 -1 天。

诚然，我的 PR 正在注释掉一行真正的旧代码，但所有单元测试似乎都通过了，它确实在我的测试中解决了这个问题。 从合作者的反馈来看。

我已经证明这是 Python 2.7 以及 Python 3.5 和 3.6 版本上的一个问题。 并不是说它不是其他版本中的错误，那些只是我设置环境的错误。

我尝试从不使用数据库进行beat 迁移到使用django-celery-beat ......这一天主要是在阅读github问题:(

使用CELERY_TIMEZONE = 'UTC'时，是否还有其他人无法使用此功能？ 我在让它与那个集合一起工作时也遇到了问题..

@xeor您可能还需要设置 CELERY_ENABLE_UTC = True

传递给 localize() 的日期时间的实际问题是，如果您为项目设置了本地而非 UTC 时区，那么该日期时间已经正确进入 localize，然后 dt = dt.astimezone(tz) 将其转换为带有毫无意义的时区的无意义的未来日期时间。

@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 和所有最新版本的 celery python 包（不是rabbitmq tho）..（抱歉，我这里没有 env 所以我可以检查）。

我有类似的问题，有时 celery-beat 不起作用（它不向代理发送任务）此外，它每 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 分钟时，它再次按预期运行。
我不知道这个错误..？

这是我在 celery 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

所以很明显正在发生的事情是 celery 在 08:28:59-08 运行任务，但是当存储 last_run_time 时，它​​仍然增加了 8 个小时的时间以获得 16:28:59-08 然后将其存储在数据库。

快速查看 schedules.py 告诉我我们正在从 crontab.is_due() 返回一个 timedelta 或 # seconds。

我没有更多的时间在这里继续挖掘，但显然 crontab 类中的某些内容正在使用 tz replaced （未转换）获得当前时间和当前时间之间的 timedelta。

我会非常怀疑replace时区的行。

好吧——如果每个有这个 bug 的人都可以克隆 master 并重新测试它是否为你解决了这个问题。 我的 PR 在昨晚被合并，我刚刚确认它修复了错误，但对于那些使用 DB 调度程序或其他后端的人来说，获得额外的确认会很好。 谢谢！

976515108a4357397a3821332e944bb85550dfa2 应用此并检查