私は両方を使用していますが、問題なく動作しています

バージョン4.0.2からバージョン4.1.0に更新した後、同様のエラーが発生し、タスクスケジューラが正しく機能しません

ここでも同じですが、4.0.2にダウングレードすると再び機能します。

このバグはタイムゾーンに関連していると思います。タイムゾーンをUTCに変更すると機能します。

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

現在のmasterブランチで再確認していただけますか？

このバグは4.1.0で確認できます

私の設定で：

CELERY_TIMEZONE = 'Europe/Moscow'

そして、はい、それはうまく機能します：

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

同じ問題-セロリビートを使用する複数のプロジェクトがありますが、そのうちの1つがたまたまCELERY_TIMEZONEをプロジェクトのタイムゾーンであるAmerica / NewYorkに設定しました。 文字通り、私はRabbit QAサーバーで1800万のメッセージで目が覚めました。これは、ワーカーがキューに入れられている速度（1分あたり数百）に追いつけなかったためです。 設定を削除し、プロジェクトをデフォルトのCELERY_TIMEZONE of Noneにすると、問題も解決しました。

FWIW--DatabaseSchedulerを使用しているとは思いません。 たぶん、問題名の名前を変更する必要がありますか？

@matteius @AyumuKasuga masterブランチでテストを実行して修正を検証できれば、それは素晴らしいことです。 問題をお詫び申し上げます。

こんにちは@georgepsarakis ！
マスターブランチをテストしたばかりですが、残念ながらセットアップでは問題が解決していません。

こっちも一緒！

やあ、

私も同様の問題を抱えています。 http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.htmlからdjango-celery-beatのセットアップ手順に従いました。

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プロジェクトは、協力的で客観的で建設的な批評家のためのものだと思います。 たわごとに何行のコードを入れましたか？ 私は実際にビートが完璧に機能しているセロリを持っています。

私はあなたがこれまでに持っているよりもはるかに高度なシステムを構築しました。 私はオペレーティングシステムを作成し、高頻度取引プラットフォームと大規模なクロスデータセンターDBを構築しました。 などなど。

コード行？ 私は機能するシステムだけを見ています。 LOCはタイロ用です。

継承したシステムで使用しているため、Celeryを使用する必要があります。 私はそれを取り除き、最初の配達が終わったら自分で書くつもりです。

ビートの問題に加えて、タスクの実行で最大1回のプロパティを確保するためにロックを使用するように人々に求めることは、巨大なジョークです。

高給の仕事を得ることができないので、あなたが得意なこと、つまり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は、プルリクエストの行で2017-10-12 22：42：27.041931 + 20：00に変換されます。
どうやらUTCモードでは、datetimeオブジェクトはコードのこの時点で同じままです。 したがって、次に起こることは、remaining_deltaの結果が-1日、タスクスケジュールより1：27：32.958069遅れていると解釈されることです。 そのため、タスクを送信し、常に遅れているため、長くスリープしません。 タスクを打ち負かし続け、タスクの期限が切れるまで常に-1日かかるためです。

確かに私のPRは実際の古いコード行をコメントアウトしていますが、それでもすべての単体テストは合格したようで、私のテストではこの問題を解決しました。 共同編集者のフィードバックから見てください。

私はこれがPython2.7とPython3.5および3.6バージョンの問題であることを示しました。 他のバージョンのバグではないことは言うまでもありませんが、それらは私が環境をセットアップしたものにすぎません。

ビートにデータベースを使用しないことから、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の両方をアンインストールし、最新バージョンでそれらを再インストールし、それは機能しました。

ありがとう..運が悪かったので、これら3つすべてを試してみました。
後で、環境をクリーンに再構築して試してみます。

@xeorまあ、この問題があなたが経験している問題ではない可能性は非常に高いですが、おそらくそうです。 このチケットのアドバイスは、これまでにこの問題が発生したすべてのユーザーに対して一貫しており、スケジュールされたタスクのキューイングが制御不能になり、タスクが蓄積され、そのために適切に処理されなくなります。 エラーや予期しない結果について多くの詳細を残していないように見えるので、具体的な問題について詳しく説明していただけますか？

いつでも喜んでお手伝いします。 DatabaseSchedulerなしでこの問題が発生し、タイムゾーンを変更するだけで修正されたことに注意してください。 私のテストでは、このバグの前後に生成されたスケジュールファイルが同一であることを示したので、バグはスケジューラーに関するものではなく、localize（）呼び出しに渡される日時のタイプに関するものだと思います。

ヘッドアップをありがとう！

来週の終わりか翌週の前に、より深いループをとることはできません。 その間、このスレッドの進捗状況について自己情報を提供し続けます。

セットアップが特別なものかどうかはわかりませんが、docker、amqp、rabbitmq、およびすべての最新バージョンのcelery 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

スケジュールにファイルデータベースを使用しています

この問題は、python 3.6.3、pytz 2017.3、django 1.11.7、celery 4.1.0、およびdjango-celery-beat1.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を保存すると、16：28：59-08を取得する時間に8時間追加されてから、 DB。

schedules.pyをざっと見てみると、crontab.is_due（）からtimedeltaまたは＃秒が返されていることがわかります。

ここで掘り下げる時間はもうありませんが、明らかにcrontabクラス内の何かが、現在の時刻と現在の時刻の間のタイムデルタをtz replaced （変換されていない）で取得しています。

replaceタイムゾーンの行は非常に疑わしいと思います。

了解しました-このバグを抱えているすべての人がマスターのクローンを作成し、問題が修正されることを再テストできれば。 私のPRは昨夜マージされ、バグが修正されたことを確認しましたが、DBスケジューラーまたは他のバックエンドを使用している場合は追加の確認を取得することをお勧めします。 ありがとう！

976515108a4357397a3821332e944bb85550dfa2これを適用して確認してください