Saya menggunakan keduanya dan keduanya berfungsi dengan baik

setelah memperbarui ke versi 4.1.0 dari versi 4.0.2 - mendapat kesalahan serupa, penjadwal tugas tidak berfungsi dengan baik

sama di sini, ketika saya menurunkan versi ke 4.0.2 berfungsi lagi.

Saya pikir bug ini terkait dengan zona waktu, ketika saya mengubah zona waktu ke UTC berfungsi.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Benar

Bisakah Anda memeriksa ulang cabang master ?

Saya dapat mengkonfirmasi bug ini di 4.1.0

di pengaturan saya:

CELERY_TIMEZONE = 'Europe/Moscow'

Dan ya itu berfungsi dengan baik dengan:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

Masalah yang sama -- kami memiliki beberapa proyek yang menggunakan ketukan seledri tetapi salah satunya terjadi untuk mengatur CELERY_TIMEZONE menjadi zona waktu proyek yaitu Amerika/NewYork. Secara harfiah saya terbangun dengan 18 juta pesan di server Rabbit QA karena para pekerja tidak dapat mengikuti laju antrian mereka -- ratusan per menit. Menghapus pengaturan dan membiarkan proyek default ke CELERY_TIMEZONE dari None juga menyelesaikan masalah.

FWIW -- Saya rasa kita tidak menggunakan DatabaseScheduler. Mungkin nama masalah harus diganti namanya?

@matteius @AyumuKasuga jika Anda dapat menjalankan tes dengan cabang master untuk memverifikasi perbaikan, itu akan sangat bagus. Maaf untuk masalah.

Halo @georgepsarakis !
Saya baru saja menguji cabang master dan sayangnya dalam pengaturan saya masalahnya masih ada.

Sama disini!

Hai,

Saya memiliki masalah serupa. Saya mengikuti instruksi pengaturan Django-celery-beat dari: 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'

Lalu saya mendefinisikan tugas berkala:

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

Saat memulai ketukan seledri, saya mendapatkan output berikut:

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

Tugas periodik ada di database dan ditandai sebagai enabled .

Namun, pekerja seledri tidak menerima atau menjalankan tugas berkala:

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

Perangkat lunak:

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

Setiap ide/bantuan untuk menyelesaikan masalah ini disambut.

Terbaik,
Sebastian

Sepotong kotoran. Ini tidak bekerja.

@mchen-scala Saya pikir proyek OSS adalah untuk berkolaborasi dan kritik yang objektif dan konstruktif. Berapa banyak baris kode yang telah Anda masukkan ke dalam kotoran? Saya sebenarnya memiliki Seledri dengan ketukan yang berfungsi dengan sempurna.

Saya telah membangun sistem yang jauh lebih maju daripada yang pernah Anda miliki. Saya telah menulis sistem operasi dan membangun platform perdagangan frekuensi tinggi dan DB lintas pusat data skala besar. Dan masih banyak lagi.

Baris kode? Saya hanya melihat sistem yang BEKERJA. LOC adalah untuk tyros.

Saya harus menggunakan Seledri karena sistem yang saya warisi menggunakannya. Saya akan menyingkirkannya dan menulis milik saya sendiri setelah pengiriman pertama kami selesai.

Selain masalah ketukan, meminta orang untuk menggunakan kunci untuk memastikan properti paling banyak dalam eksekusi tugas adalah LELUCON GIGANTIC.

Tetap berpegang pada apa yang Anda kuasai, yaitu OSS karena Anda tidak bisa mendapatkan pekerjaan bergaji tinggi.

@mchen-scala Anda belum pernah menulis sistem yang kompleks dalam hidup Anda, Anda bahkan tidak dapat memahami konteks tiket ini, yaitu bahwa dalam seri Seledri 4 ada beberapa versi di mana CELERY_BEAT_SCHEDULE tidak diikuti jika zona waktu tidak UTC.

Poin Anda semuanya tidak akurat dan menghina di banyak tingkatan. Leluconnya adalah Anda datang ke sini untuk menghina kami karena mengerjakan proyek OSS yang memenuhi kebutuhan banyak orang di banyak industri. Saya akan berasumsi bahwa apa pun yang pernah Anda tulis untuk seorang majikan belum pernah dilihat sebanyak proyek Seledri. Karena Anda sebenarnya belum mereferensikan karya Anda sebelumnya. Di dunia yang gesit Anda akan merilis setiap 2-4 minggu, jadi fakta bahwa Anda sedang mengerjakan proyek yang Anda warisi alih-alih sistem luar biasa yang seharusnya Anda bangun ini hanya menunjukkan kepada saya bahwa Anda memiliki rasa harga diri yang meningkat.

Selanjutnya mchen-scala, saya mendorong Anda untuk mematikan seledri--terutama karena kami tidak membutuhkan sikap Anda di komunitas kami. Saya memiliki pekerjaan bergaji tinggi karena saya dapat memanfaatkan OSS dan memberikan dukungan untuk memperbaiki masalah yang muncul. Saya sarankan Anda mengikuti mantra Anda sendiri dan tetap berpegang pada apa yang Anda kuasai, yang tampaknya menggulirkan solusi Anda sendiri untuk masalah dengan solusi yang ada, dan menjadi brengsek antisosial bagi kita semua. Sia!

Saya telah menunjukkan dengan tepat baris kode yang mengubah datetime sadar zona waktu saya menjadi datetime mendatang dalam offset +20 yang saya yakin bukan offset zona waktu nyata.
2017-10-11 22:42:27.041931-04:00 akan dikonversi ke 2017-10-12 22:42:27.041931+20:00 pada baris di Permintaan Tarik saya.
Rupanya dalam mode UTC objek datetime tetap sama pada titik ini dalam kode. Jadi yang terjadi selanjutnya adalah hasil dari residual_delta diinterpretasikan sebagai -1 hari, 1:27:32.958069 di belakang jadwal tugas. Jadi mengirimkan tugas dan tidak tidur lama karena selalu di belakang. Itu terus mengalahkan tugas, selalu karena -1 hari sampai tugas jatuh tempo.

Memang PR saya mengomentari baris kode lama yang sebenarnya, namun semua tes unit tampaknya lulus dan itu menyelesaikan masalah ini dalam pengujian saya. Melihat dari umpan balik kolaborator.

Saya telah menunjukkan ini sebagai masalah pada versi Python 2.7 serta Python 3.5 dan 3.6. Bukan untuk mengatakan itu bukan bug di versi lain, itu hanya yang saya setel dengan lingkungan.

Saya mencoba bermigrasi dari tidak menggunakan database untuk beat, ke menggunakan Django-celery-beat... Hari ini sebagian besar membaca masalah github :(

Apakah ada orang lain yang tidak menjalankan ini saat menggunakan CELERY_TIMEZONE = 'UTC' ? Saya mengalami masalah membuatnya bekerja dengan set itu juga ..

@xeor Anda mungkin juga perlu menyetel CELERY_ENABLE_UTC = True

Masalah aktual dari datetime yang diteruskan ke localize() adalah bahwa jika Anda memiliki zona waktu lokal bukan UTC yang ditetapkan untuk proyek Anda, maka datetime tersebut sudah benar masuk ke lokalisasi dan kemudian dt = dt.astimezone(tz) mengubahnya menjadi a datetime masa depan yang tidak masuk akal dengan zona waktu yang tidak masuk akal.

@xeor saya mengalami masalah yang sama bahkan dengan pengaturan berikut:

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

Sekarang, saya tahu ini tampak konyol, tetapi saya menghapus Celery dan Django-celery-beat, dan menginstalnya lagi dengan versi terbaru mereka dan berhasil.

Terima kasih .. Saya telah mencoba dengan semua 3 juga, tanpa hasil.
Saya akan mencobanya nanti dengan membangun kembali lingkungan yang bersih..

@xeor Yah, sangat mungkin bahwa masalah ini bukan masalah yang Anda alami, meskipun mungkin memang demikian. Saran dalam tiket ini telah konsisten untuk semua pengguna yang mengalami masalah ini sejauh ini, yang menyebabkan antrian tugas terjadwal yang tidak terkendali dan tugas tersebut menumpuk dan tidak diproses dengan benar karena itu. Bisakah Anda menjelaskan lebih banyak masalah spesifik Anda karena tampaknya Anda tidak meninggalkan banyak detail tentang kesalahan atau hasil tak terduga yang Anda dapatkan?

Selalu senang membantu. Hanya mencatat bahwa kami memiliki masalah ini tanpa DatabaseScheduler dan memperbaikinya dengan hanya mengubah zona waktu. Dalam pengujian saya, saya menunjukkan bahwa file jadwal yang dihasilkan sebelum dan sesudah bug ini identik jadi saya benar-benar tidak berpikir bug itu tentang penjadwal melainkan jenis datetime yang diteruskan ke panggilan localize().

Terimakasih atas peringatannya!

Saya tidak akan dapat mengambil lingkaran yang lebih dalam sebelum mungkin akhir minggu depan atau minggu sesudahnya. Saya akan terus memberi tahu diri saya tentang kemajuan di utas ini untuk sementara waktu.

Saya tidak yakin apakah pengaturan saya adalah sesuatu yang istimewa, tetapi saya menggunakan buruh pelabuhan, amqp, rabbitmq dan semua versi terbaru dari paket python seledri (bukan rabbitmq tho) .. (maaf, saya tidak memiliki env di sini jadi saya bisa cek)..

Saya memiliki masalah serupa, beberapa kali celery-beat tidak berfungsi (tidak mengirim tugas ke broker) Selain itu, ia mengirim terlalu banyak tugas setiap 59 menit
Saya membuat tugas tes untuk dijalankan setiap menit

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

Pada menit 59, banyak tugas mulai berjalan dan ketika waktu mencapai menit 0 itu berjalan seperti yang diharapkan lagi.
Saya tidak tahu tentang bug ini ..?

Ini adalah pengaturan saya di seledri 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

Saya menggunakan file db untuk jadwal

Saya memiliki masalah ini juga pada python 3.6.3, pytz 2017.3, Django 1.11.7, celery 4.1.0 dan Django-celery-beat 1.1.0.

Saya menghapus database terlebih dahulu:

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

Dan antrian terus terisi dengan kecepatan 600/detik.

# 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 

Pengaturan saya adalah (saya mengatur semua yang dapat saya temukan karena dokumentasinya sangat tidak jelas dan ketinggalan zaman di beberapa tempat):

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

Jadi jelas yang terjadi adalah seledri menjalankan tugas pada 08:28:59-08, tetapi kemudian ketika menyimpan last_run_time, masih menambahkan 8 jam ke waktu untuk mendapatkan 16:28:59-08 sebelum menyimpannya di DB-nya.

Melihat sekilas ke schedule.py memberi tahu saya bahwa kami mengembalikan timedelta atau # detik dari crontab.is_due().

Saya tidak punya lebih banyak waktu untuk terus menggali di sini, tetapi jelas sesuatu di dalam kelas crontab mendapatkan delta waktu antara waktu saat ini dan waktu saat ini dengan tz replaced (tidak dikonversi).

Saya akan sangat curiga dengan garis yang replace zona waktu.

Baiklah -- Jika semua orang yang memiliki bug ini dapat mengkloning master dan menguji ulang bahwa itu memperbaiki masalah untuk Anda. PR saya digabungkan tadi malam dan saya baru saja memverifikasi bahwa itu memperbaiki bug tetapi akan lebih baik untuk mendapatkan konfirmasi tambahan untuk mereka yang menggunakan penjadwal DB atau backend lainnya. Terima kasih!

976515108a4357397a3821332e944bb85550dfa2 terapkan ini dan periksa