Estoy usando ambos y funcionan bien

después de actualizar a la versión 4.1.0 desde la versión 4.0.2 - obtuvo un error similar, el programador de tareas no funciona correctamente

Lo mismo aquí, cuando baje a 4.0.2, funciona de nuevo.

Creo que este error está relacionado con la zona horaria, cuando cambio la zona horaria a UTC, funciona.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Verdadero

¿Podría volver a verificar con la sucursal actual master ?

Puedo confirmar este error en 4.1.0

en mi configuración:

CELERY_TIMEZONE = 'Europe/Moscow'

Y sí, funciona bien con:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

El mismo problema: tenemos varios proyectos que usan apio, pero uno de ellos configuró CELERY_TIMEZONE como la zona horaria del proyecto, que era América / NuevaYork. Literalmente, me desperté con 18 millones de mensajes en el servidor de control de calidad de Rabbit porque los trabajadores no podían mantenerse al día con la velocidad a la que están en cola: cientos por minuto. Eliminar la configuración y dejar que el proyecto tenga el valor predeterminado CELERY_TIMEZONE de Ninguno también resolvió el problema.

FWIW: no creo que estemos usando DatabaseScheduler. ¿Quizás se debería cambiar el nombre del problema?

@matteius @AyumuKasuga si puede ejecutar una prueba con la rama master para verificar la solución, sería genial. Perdón por los problemas.

¡Hola @georgepsarakis !
Acabo de probar la rama maestra y, desafortunadamente, en mi configuración el problema persiste.

¡Aquí igual!

Hola,

Tengo un problema similar. Seguí las instrucciones de configuración de django-celery-beat de: 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'

Luego defino una tarea periódica:

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

Al iniciar el batido de apio, obtengo el siguiente 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...

La tarea periódica existe en la base de datos y está marcada como enabled .

Sin embargo, un trabajador de apio no recibe ni ejecuta ninguna tarea 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

Software:

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

Cualquier idea / ayuda para resolver este problema es bienvenida.

Mejor,
Sebastián

Un pedazo de mierda. No funciona.

@ mchen-scala Creo que los proyectos de OSS son para la crítica colaboradora y objetiva y constructiva. ¿Cuántas líneas de códigos has puesto en el pedazo de mierda? De hecho, tengo apio con ritmo funcionando perfectamente.

He construido sistemas mucho más avanzados de los que jamás habrás hecho. He escrito sistemas operativos y construido plataformas de negociación de alta frecuencia y bases de datos de centros de datos cruzados a gran escala. Y muchos más.

¿Líneas de código? Solo miro los sistemas que FUNCIONAN. LOC es para tiros.

Tengo que usar Celery porque el sistema que heredé lo usa. Voy a deshacerme de él y escribir el mío una vez que hayamos terminado nuestra primera entrega.

Además del problema del ritmo, pedirle a la gente que use un candado para garantizar una propiedad como máximo en la ejecución de la tarea es una BROMA GIGÁNTICA.

Cíñete a aquello en lo que eres bueno, que es OSS, ya que no puedes conseguir trabajos bien pagados.

@ mchen-scala Nunca has escrito un sistema complejo en tu vida, ni siquiera puedes entender el contexto de este ticket, que es que en la serie Celery 4 hay algunas versiones donde el CELERY_BEAT_SCHEDULE no se sigue si la zona horaria no es UTC.

Tus puntos son inexactos e insultantes en muchos niveles. La broma es que vienes aquí para insultarnos por trabajar en un proyecto de OSS que se adapta a las necesidades de muchas personas en muchas industrias. Voy a asumir que cualquier cosa que haya escrito para un empleador no ha visto tanta luz como el proyecto de Apio. Como en realidad no ha hecho referencia a ninguno de sus trabajos anteriores. En un mundo ágil, estarías lanzando cada 2 a 4 semanas, por lo que el hecho de que estés trabajando en un proyecto que heredaste en lugar de estos increíbles sistemas que supuestamente construiste solo me indica que tienes un sentido inflado de autoestima.

Además, mchen-scala, le animo a que apague el apio, principalmente porque no necesitamos sus actitudes en nuestra comunidad. Tengo un trabajo bien remunerado porque puedo aprovechar OSS y brindar apoyo para solucionar problemas a medida que surgen. Te sugiero que sigas tu propio mantra y te ciñas a lo que eres bueno, que aparentemente es desarrollar tus propias soluciones a los problemas con las soluciones existentes y ser un idiota antisocial para el resto de nosotros. ¡Cya!

He señalado la línea exacta de código que está convirtiendo mi fecha y hora que ya conoce la zona horaria en una fecha y hora futura en un desplazamiento +20 que estoy seguro de que no es un desplazamiento real de la zona horaria.
2017-10-11 22: 42: 27.041931-04: 00 se convierte a 2017-10-12 22: 42: 27.041931 + 20: 00 en la línea de mi Pull Request.
Aparentemente, en el modo UTC, el objeto de fecha y hora permanece igual en este punto del código. Entonces, lo que sucede a continuación es que el resultado de resident_delta se interpreta como -1 día, 1:27: 32.958069 por detrás del cronograma de tareas. Entonces envía la tarea y no duerme mucho porque siempre está atrasado. Simplemente sigue superando las tareas, siempre porque son -1 días hasta que la tarea se vence.

De acuerdo, mi PR está comentando una línea de código realmente antigua y, sin embargo, todas las pruebas unitarias parecieron pasar y resolvió este problema en mis pruebas. A partir de los comentarios de los colaboradores.

He demostrado que esto es un problema en Python 2.7, así como en las versiones Python 3.5 y 3.6. Por no decir que no es un error en otras versiones, esas son solo aquellas con las que configuro entornos.

Traté de migrar de no usar la base de datos para beat, a usar django-celery-beat ... El día ha estado principalmente leyendo problemas de github :(

¿Hay alguien más que no haga que esto funcione al usar CELERY_TIMEZONE = 'UTC' ? También tengo problemas para que funcione con ese conjunto.

@xeor Es posible que también deba configurar CELERY_ENABLE_UTC = True

El problema real de la fecha y hora que se pasa a localize () es que si tiene una zona horaria local no UTC configurada para su proyecto, entonces esa fecha y hora ya es correcta al ingresar a la localización y luego dt = dt.astimezone (tz) lo transforma en una fecha y hora futura sin sentido con una zona horaria que no tiene sentido.

@xeor estaba teniendo el mismo problema incluso con la siguiente configuración:

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

Ahora, sé que parece una tontería, pero desinstalé tanto Celery como django-celery-beat, los instalé de nuevo con su última versión y funcionó.

Gracias ... He probado con todos esos 3 también, sin suerte.
Lo intentaré más tarde con una reconstrucción limpia del medio ambiente.

@xeor Bueno, es muy posible que este problema no sea el problema que está experimentando, aunque tal vez lo sea. El consejo en este ticket ha sido coherente para todos los usuarios que experimentan este problema hasta ahora, lo que lleva a una puesta en cola fuera de control de las tareas programadas y a las tareas que se acumulan y no se procesan correctamente debido a eso. ¿Podría describir más su problema específico, ya que no parece que haya dejado muchos detalles sobre los errores o el resultado inesperado que está obteniendo?

Siempre feliz de ayudar. Solo notando que tuvimos este problema sin DatabaseScheduler y lo solucionamos cambiando solo las zonas horarias. En mis pruebas, mostré que el archivo de programación generado antes y después de este error era idéntico, por lo que realmente no creo que el error sea sobre el programador, sino sobre el tipo de fecha y hora que se pasa a la llamada localize ().

¡Gracias por el aviso!

No podré hacer un ciclo más profundo antes tal vez a fines de la próxima semana o la semana siguiente. Mientras tanto, me mantendré informado sobre el progreso de este hilo.

No estoy seguro de si mi configuración es algo especial, pero estoy usando docker, amqp, rabbitmq y todas las versiones más recientes de los paquetes de celery python (no rabbitmq tho) .. (lo siento, no tengo el env aquí, así que poder revisar)..

Tengo un problema similar, algunas veces apio-beat no funciona (no envía la tarea al corredor) Además, envía demasiadas tareas cada 59 minutos
Hice una tarea de prueba para ejecutar 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)

En el minuto 59, un grupo de tareas comienza a ejecutarse y cuando el tiempo llega al minuto 0, se ejecuta de nuevo como se esperaba.
No tengo ni idea de este error ..?

Este es mi escenario en apio 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

Estoy usando el archivo db para programar

También tengo este problema en python 3.6.3, pytz 2017.3, django 1.11.7, celery 4.1.0 y django-celery-beat 1.1.0.

Primero limpio la base de datos:

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

Y la cola continúa llenándose a una velocidad de 600 / seg.

# 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 

Mi configuración es (configuré todo lo que pude encontrar porque la documentación es extremadamente poco clara y desactualizada en varios 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

Entonces, está claro que lo que está sucediendo es que el apio ejecuta la tarea a las 08: 28: 59-08, pero luego, al almacenar el last_run_time, todavía está agregando 8 horas al tiempo para obtener 16: 28: 59-08 antes de almacenarlo en el DB.

Echar un vistazo rápido a schedule.py me dice que estamos devolviendo un timedelta o # segundos de crontab.is_due ().

No tengo más tiempo para seguir investigando aquí, pero obviamente algo dentro de la clase crontab está obteniendo un timedelta entre la hora actual y la hora actual con su tz replaced (no convertido).

Sospecharía mucho de las líneas que replace zonas horarias.

Muy bien, si todos los que tenían este error pudieran clonar el maestro y volver a probar que soluciona el problema. Mi PR se fusionó anoche y acabo de verificar que solucionó el error, pero sería bueno obtener una confirmación adicional de eso para aquellos que usan el programador DB u otros backends. ¡Gracias!

976515108a4357397a3821332e944bb85550dfa2 aplique esto y verifique