Estou usando os dois e eles estão funcionando bem

após atualizar para a versão 4.1.0 da versão 4.0.2 - ocorreu um erro semelhante, o agendador de tarefas não funciona corretamente

mesmo aqui, quando eu faço o downgrade para 4.0.2 ele funciona novamente.

Acho que esse bug está relacionado ao fuso horário, quando eu mudo o fuso horário para UTC funciona.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Verdadeiro

Você poderia verificar novamente com a filial master atual?

Posso confirmar esse bug em 4.1.0

em minhas configurações:

CELERY_TIMEZONE = 'Europe/Moscow'

E sim, funciona bem com:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

Mesmo problema - temos vários projetos usando a batida de aipo, mas um deles definiu CELERY_TIMEZONE como o fuso horário do projeto que era América / Nova York. Literalmente, acordei com 18 milhões de mensagens no servidor Rabbit QA porque os funcionários não conseguiam acompanhar a taxa com que estavam enfileirados - centenas por minuto. Excluir as configurações e deixar o padrão do projeto em CELERY_TIMEZONE de Nenhum também resolveu o problema.

FWIW - Acho que não estamos usando o DatabaseScheduler. Talvez o nome do problema deva ser renomeado?

@matteius @AyumuKasuga se você puder executar um teste com o branch master para verificar a correção, seria ótimo. Desculpe pelos problemas.

Olá @georgepsarakis !
Acabei de testar o branch master e, infelizmente, em minha configuração, o problema ainda existe.

Mesmo aqui!

Oi,

Eu tenho um problema similar. Segui as instruções de configuração do django-celery-beat em: 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'

Então eu defino uma tarefa periódica:

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

Ao iniciar a batida do aipo, obtenho o seguinte resultado:

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

A tarefa periódica existe no banco de dados e está marcada como enabled .

No entanto, um trabalhador de aipo não recebe ou executa nenhuma tarefa periódica:

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

Programas:

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

Qualquer ideia / ajuda para resolver este problema é bem-vinda.

Melhor,
Sebastian

Um pedaço de merda. Não funciona.

@mchen-scala Acho que os projetos de OSS são para colaboração e críticos objetivos e construtivos. Quantas linhas de código você colocou neste pedaço de merda? Na verdade, tenho o Celery com batimento funcionando perfeitamente.

Construí sistemas muito mais avançados do que você jamais terá. Eu escrevi sistemas operacionais e construí plataformas de negociação de alta frequência e bancos de dados entre datacenters em grande escala. E muitos mais.

Linhas de código? Eu apenas olho para sistemas que FUNCIONAM. LOC é para tiros.

Tenho que usar o Celery porque o sistema que herdei o usa. Vou me livrar dele e escrever o meu depois de fazermos nossa primeira entrega.

Além do problema da batida, pedir às pessoas que usem um bloqueio para garantir a propriedade de no máximo uma vez na execução da tarefa é uma PIADA GIGÂNTICA.

Atenha-se ao que você faz bem, que é o OSS, já que não consegue empregos com altos salários.

@ mchen-scala Você nunca escreveu um sistema complexo em sua vida, você nem consegue entender o contexto deste tíquete, que é que no Celery 4 series existem algumas versões onde CELERY_BEAT_SCHEDULE não é seguido se o fuso horário não for UTC.

Todos os seus pontos são imprecisos e ofensivos em muitos níveis. A piada é que você veio aqui para nos insultar por trabalhar em um projeto de software de fonte aberta que atende às necessidades de muitas pessoas em diversos setores. Vou presumir que qualquer coisa que você já escreveu para um empregador não viu tanta luz do dia quanto o projeto Aipo. Como você realmente não referenciou nenhum de seus trabalhos anteriores. Em um mundo ágil, você estaria lançando a cada 2-4 semanas, então o fato de estar trabalhando em um projeto que você herdou em vez desses sistemas incríveis que você supostamente construiu apenas indica para mim que você tem um senso inflado de auto-estima.

Além disso, mchen-scala, encorajo você a desligar o aipo - principalmente porque não precisamos de suas atitudes em nossa comunidade. Tenho um trabalho bem remunerado porque sou capaz de alavancar o OSS e fornecer suporte para corrigir problemas conforme eles surgem. Eu sugiro que você siga seu próprio mantra e se atenha ao que você é bom, que aparentemente é criar suas próprias soluções para problemas com as soluções existentes e ser um idiota anti-social para o resto de nós. Cya!

Eu apontei a linha exata de código que está convertendo minha data e hora já ciente do fuso horário em uma data e hora futura em um deslocamento +20 que tenho certeza que não é um deslocamento de fuso horário real.
2017-10-11 22: 42: 27.041931-04: 00 é convertido para 2017-10-12 22: 42: 27.041931 + 20: 00 na linha do meu Pull Request.
Aparentemente, no modo UTC, o objeto datetime permanece o mesmo neste ponto do código. Portanto, o que acontece a seguir é que o resultado de permanent_delta é interpretado como sendo -1 dia, 1: 27: 32.958069 atrasado na programação da tarefa. Então ele envia a tarefa e não dorme muito porque está sempre atrás. Ele apenas continua batendo as tarefas, sempre porque seus -1 dias até o vencimento da tarefa.

Admito que meu PR está comentando uma linha de código realmente antiga e, ainda assim, todos os testes de unidade pareceram passar e isso resolveu esse problema em meus testes. Procurando o feedback do colaborador.

Mostrei que isso é um problema no Python 2.7, bem como nas versões Python 3.5 e 3.6. Não quer dizer que não seja um bug em outras versões, essas são apenas aquelas com as quais configurei ambientes.

Eu tentei migrar de não usar o banco de dados para bater, para usar django-celery-beat ... O dia tem sido principalmente lendo problemas do github :(

Há mais alguém que não está conseguindo fazer isso funcionar ao usar CELERY_TIMEZONE = 'UTC' ? Estou tendo problemas para fazer funcionar com esse conjunto também.

@xeor Você também pode precisar definir CELERY_ENABLE_UTC = True

O problema real da data e hora sendo passada para localize () é que se você tiver um fuso horário local não UTC definido para seu projeto, então essa data e hora já está correta indo para localizar e então dt = dt.astimezone (tz) transforma isso em um data e hora futura sem sentido com um fuso horário que não faz sentido.

@xeor Eu estava tendo o mesmo problema, mesmo com as seguintes configurações:

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

Agora, eu sei que parece bobo, mas eu desinstalei o Celery e o django-celery-beat e instalei-os novamente com sua versão mais recente e funcionou.

Obrigado .. Eu tentei com todos esses 3 também, sem sorte.
Vou tentar mais tarde com uma reconstrução limpa do ambiente.

@xeor Bem, é bem possível que esse problema não seja o que você está enfrentando, embora talvez seja. O conselho neste tíquete tem sido consistente para todos os usuários com esse problema até agora, o que leva a um enfileiramento descontrolado de tarefas agendadas e a acumulação de tarefas que não são processadas adequadamente por causa disso. Você poderia descrever mais seu problema específico, visto que não parece que você deixou muitos detalhes sobre o (s) erro (s) ou o resultado inesperado que está obtendo?

Sempre feliz em ajudar. Apenas observando que tivemos esse problema sem o DatabaseScheduler e o corrigimos alterando apenas os fusos horários. Em meus testes, mostrei que o arquivo de agendamento gerado antes e depois desse bug era idêntico, então realmente não acho que o bug seja sobre o agendador, mas sim o tipo de datetimes que está sendo passado para a chamada localize ().

Obrigado pelo aviso!

Não serei capaz de fazer um loop mais profundo antes, talvez, no final da semana que vem ou na semana seguinte. Vou me manter informado sobre o progresso neste tópico nesse meio tempo.

Não tenho certeza se minha configuração é algo especial, mas estou usando docker, amqp, rabbitmq e todas as versões mais recentes de pacotes de python aipo (não rabbitmq tho) .. (desculpe, não tenho o env aqui, então eu pode verificar)..

Eu tenho um problema semelhante, algumas vezes a batida de aipo não funciona (não envia tarefas ao corretor). Além disso, envia muitas tarefas a cada 59 minutos
Eu fiz uma tarefa de teste para executar a cada minuto

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

No minuto 59, várias tarefas começam a ser executadas e quando o tempo chega ao minuto 0, ela é executada conforme o esperado novamente.
Eu não tenho ideia sobre esse bug ..?

Esta é a minha configuração no aipo 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

Estou usando o arquivo db para agendar

Também tenho esse problema no python 3.6.3, pytz 2017.3, django 1.11.7, celery 4.1.0 e django-celery-beat 1.1.0.

Eu limpo o banco de dados primeiro:

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

E a fila continua a encher a uma taxa de 600 / s.

# 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 

Minhas configurações são (eu configurei tudo que pude encontrar porque a documentação é extremamente confusa e desatualizada em vários lugares):

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

Portanto, está claro que o que está acontecendo é que o aipo executa a tarefa às 08: 28: 59-08, mas ao armazenar o last_run_time, ele ainda está adicionando 8 horas ao tempo para obter 16: 28: 59-08 antes de armazená-lo em o DB.

Uma olhada rápida em Schedules.py me diz que estamos retornando um timedelta ou # segundos de crontab.is_due ().

Não tenho mais tempo para continuar cavando aqui, mas obviamente algo dentro da classe crontab está obtendo um intervalo de tempo entre a hora atual e a hora atual com seu tz replaced (não convertido).

Eu desconfiaria muito de linhas que replace fusos horários.

Tudo bem - se todos que tinham esse bug pudessem clonar o master e testá-lo novamente, ele corrigirá o problema para você. Meu PR foi mesclado ontem à noite e eu acabei de verificar que ele corrigiu o bug, mas seria bom obter uma confirmação adicional disso para aqueles que usam o agendador de banco de dados ou outros back-ends. Obrigado!

976515108a4357397a3821332e944bb85550dfa2 aplique isso e verifique