나는 둘 다 사용하고 있고 그들은 잘 작동합니다

버전 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_TIMEZONE을 America/NewYork인 프로젝트 시간대로 설정했습니다. 문자 그대로 나는 Rabbit QA 서버에서 1,800만 개의 메시지로 잠에서 깼습니다. 작업자가 대기열에 추가되는 속도(분당 수백 개)를 따라잡을 수 없었기 때문입니다. 설정을 삭제하고 프로젝트 기본값을 없음의 CELERY_TIMEZONE으로 설정해도 문제가 해결되었습니다.

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 프로젝트가 협력적이고 객관적이고 건설적인 비평가를 위한 것이라고 생각합니다. 몇 줄의 코드를 똥 조각에 넣었습니까? 실제로 비트가 있는 Celery가 완벽하게 작동합니다.

나는 당신이 지금까지 가지고 있는 것보다 훨씬 더 진보된 시스템을 구축했습니다. 저는 운영 체제를 작성하고 빈도가 높은 거래 플랫폼과 대규모 데이터 센터 간 DB를 구축했습니다. 그리고 더 많은.

코드 줄? 나는 작동하는 시스템만 봅니다. LOC는 tyros를 위한 것입니다.

제가 물려받은 시스템이 Celery를 사용하기 때문에 Celery를 사용해야 합니다. 나는 그것을 없애고 우리가 첫 번째 배달을 마치면 내 자신을 쓸 것입니다.

비트 문제 외에도 작업 실행에서 최대 한 번 속성을 보장하기 위해 잠금을 사용하도록 사람들에게 요청하는 것은 엄청난 농담입니다.

당신은 고임금 직업을 가질 수 없기 때문에 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 모드에서 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로 설정해야 할 수도 있습니다.

localize()로 전달되는 datetime의 실제 문제는 프로젝트에 대해 UTC가 아닌 지역 시간대가 설정되어 있는 경우 해당 datetime이 이미 localize로 들어가는 것이 정확하고 dt = dt.astimezone(tz)이 이를 a로 변환한다는 것입니다. 의미가 없는 시간대가 포함된 무의미한 미래 날짜/시간입니다.

@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가 아님)를 사용하고 있습니다. 확인할 수 있습니다)..

비슷한 문제가 있습니다. 때때로 celery-beat가 작동하지 않습니다(중개업체에 작업을 보내지 않음). 또한 59분마다 너무 많은 작업을 보냅니다.
1분마다 실행되는 테스트 작업을 만들었습니다.

[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을 저장할 때 저장하기 전에 16:28:59-08을 얻는 데 여전히 8시간이 추가된다는 것입니다. DB.

schedules.py를 간단히 살펴보면 crontab.is_due()에서 timedelta 또는 #초를 반환하고 있음을 알 수 있습니다.

여기에서 계속 파고들 시간이 없지만 분명히 crontab 클래스 내부의 무언가가 현재 시간과 현재 시간 사이의 tz replaced (변환되지 않음)를 사용하여 timedelta를 얻고 있습니다.

나는 replace 시간대의 라인을 매우 의심할 것입니다.

알겠습니다 -- 이 버그가 있는 모든 사람이 마스터를 복제하고 문제가 해결되는지 다시 테스트할 수 있다면. 지난 밤에 제 PR이 병합되었고 버그가 수정되었음을 방금 확인했지만 DB 스케줄러 또는 기타 백엔드를 사용하는 사람들을 위해 추가 확인을 받는 것이 좋습니다. 감사 해요!

976515108a4357397a3821332e944bb85550dfa2 이것을 적용하고 확인