Apio Tarea de tipo no registrada recibida (ejemplo de ejecución)


96

Estoy tratando de ejecutar un ejemplo de la documentación de Celery.

Corro: celeryd --loglevel=INFO

/usr/local/lib/python2.7/dist-packages/celery/loaders/default.py:64: NotConfigured: No 'celeryconfig' module found! Please make sure it exists and is available to Python.
  "is available to Python." % (configname, )))
[2012-03-19 04:26:34,899: WARNING/MainProcess]  

 -------------- celery@ubuntu v2.5.1
---- **** -----
--- * ***  * -- [Configuration]
-- * - **** ---   . broker:      amqp://guest@localhost:5672//
- ** ----------   . loader:      celery.loaders.default.Loader
- ** ----------   . logfile:     [stderr]@INFO
- ** ----------   . concurrency: 4
- ** ----------   . events:      OFF
- *** --- * ---   . beat:        OFF
-- ******* ----
--- ***** ----- [Queues]
 --------------   . celery:      exchange:celery (direct) binding:celery

tasks.py:

# -*- coding: utf-8 -*-
from celery.task import task

@task
def add(x, y):
    return x + y

run_task.py:

# -*- coding: utf-8 -*-
from tasks import add
result = add.delay(4, 4)
print (result)
print (result.ready())
print (result.get())

En la misma carpeta celeryconfig.py:

CELERY_IMPORTS = ("tasks", )
CELERY_RESULT_BACKEND = "amqp"
BROKER_URL = "amqp://guest:guest@localhost:5672//"
CELERY_TASK_RESULT_EXPIRES = 300

Cuando ejecuto "run_task.py":

en la consola de Python

eb503f77-b5fc-44e2-ac0b-91ce6ddbf153
False

errores en el servidor de celeryd

[2012-03-19 04:34:14,913: ERROR/MainProcess] Received unregistered task of type 'tasks.add'.
The message has been ignored and discarded.

Did you remember to import the module containing this task?
Or maybe you are using relative imports?
Please see http://bit.ly/gLye1c for more information.

The full contents of the message body was:
{'retries': 0, 'task': 'tasks.add', 'utc': False, 'args': (4, 4), 'expires': None, 'eta': None, 'kwargs': {}, 'id': '841bc21f-8124-436b-92f1-e3b62cafdfe7'}

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/celery/worker/consumer.py", line 444, in receive_message
    self.strategies[name](message, body, message.ack_log_error)
KeyError: 'tasks.add'

Explique cuál es el problema.


12
Hola, ¿podrías compartir cuál fue el problema y cómo lo resolviste? La respuesta aceptada no deja claro cómo otros podrían resolver este problema. Gracias.
Jordan Reiter

3
Estoy con Jordan, esto no fue útil en absoluto. Voto en contra.
Jay Taylor

2
la respuesta de aiho es la correcta:CELERY_IMPORTS = ("tasks", )
Alp

Respuestas:


50

Puede ver la lista actual de tareas registradas en la celery.registry.TaskRegistryclase. Podría ser que su configuración de apio (en el directorio actual) no esté en, PYTHONPATHpor lo que apio no puede encontrarla y vuelve a los valores predeterminados. Simplemente especifíquelo explícitamente al comenzar con el apio.

celeryd --loglevel=INFO --settings=celeryconfig

También puede configurar --loglevel=DEBUGy probablemente debería ver el problema de inmediato.


4
+1 para --loglevel=DEBUG, hubo un error de sintaxis en mi tarea.
Jacob Valenta

12
el apio está obsoleto. Ahora uno debería correr, celery workerpor ejemplo, para Djangoestocelery --app=your_app.celery worker --loglevel=info
andilabs

Para mí (apio 3.1.23), tuve que usar celery.registry.taskspara ver una lista de todas mis tareas actuales. Siempre puedes comprobarlo corriendo dir(celery.registry).
Nick Brady

porque --loglevel=DEBUGde mi lado también
Shobi

64

Creo que necesitas reiniciar el servidor trabajador. Encuentro el mismo problema y lo resuelvo reiniciando.


8
¡Gracias! Ojalá hubiera encontrado esto hace una hora
Nexus

2
Esto me lo arregló. Si está utilizando scripts de apio, el trabajador importa sus módulos de tareas al inicio. Incluso si luego crea más funciones de tarea o modifica las existentes, el trabajador usará sus copias en memoria como estaban cuando las leyó.
Mark

1
Nota: puede verificar que sus tareas estén o no registradas ejecutandocelery inspect registered
Nick Brady

1
También puede iniciar el apio con la opción --autoreloadque reiniciará el apio cada vez que se cambie el código.
Sergey Lyapustin

Desafortunadamente en desuso. Se podría usar una solución de este enlace: avilpage.com/2017/05/…
Tomasz Szkudlarek

50

Tuve el mismo problema: la razón "Received unregistered task of type.."fue que el servicio de apio no encontró ni registró las tareas al inicio del servicio (por cierto, su lista es visible cuando comienzas ./manage.py celeryd --loglevel=info).

Estas tareas deben declararse en el CELERY_IMPORTS = ("tasks", )archivo de configuración.
Si tiene un celery_settings.pyarchivo especial , debe declararse en el inicio del servicio de --settings=celery_settings.pyceleryd como escribió digivampire.


1
Gracias, de hecho tuve el problema porque comencé a usar celery usando ~ / path / to / celery / celeryd en lugar de usar el comando manage.py!
Antoine

27

Ya sea que use CELERY_IMPORTS oautodiscover_tasks , lo importante es que las tareas se pueden encontrar y el nombre de las tareas registradas en Celery debe coincidir con los nombres que los trabajadores intentan buscar.

Cuando inicie el Apio, digamos celery worker -A project --loglevel=DEBUG, debería ver el nombre de las tareas. Por ejemplo, si tengo una debug_tasktarea en mi celery.py.

[tasks]
. project.celery.debug_task
. celery.backend_cleanup
. celery.chain
. celery.chord
. celery.chord_unlock
. celery.chunks
. celery.group
. celery.map
. celery.starmap

Si no puede ver sus tareas en la lista, por favor verifica la importación de configuración de apio las tareas correctamente, ya sea en --setting, --config, celeryconfigoconfig_from_object .

Si está utilizando apio batido, asegúrese de que el nombre de la tarea task, que utiliza en CELERYBEAT_SCHEDULEcoincide con el nombre en la lista de tareas de apio.


Esto fue muy útil. El nombre de la tarea debe coincidir con la clave 'tarea' en su CELERYBEAT_SCHEDULE
ss_millionaire

* El punto importante es que las tareas se pueden encontrar y el nombre de las tareas registradas en Celery debe coincidir con los nombres que los trabajadores intentan buscar. * ¡¡¡Buen punto!!!
Light.G

Esta es la respuesta correcta. El nombre de su tarea en BEAT_SCHEDULER debe coincidir con lo que aparezca en la lista de tareas descubiertas automáticamente. Entonces, si lo usó @task(name='check_periodically'), debería coincidir con lo que puso en el calendario de tiempos, IE:CELERY_BEAT_SCHEDULE = { 'check_periodically': { 'task': 'check_periodically', 'schedule': timedelta(seconds=1) }
Mormoran

16

También tuve el mismo problema; yo añadí

CELERY_IMPORTS=("mytasks")

en mi celeryconfig.pyarchivo para solucionarlo.


6
Tenga en cuenta que debe ser una lista o una tupla:CELERY_IMPORTS = ['my_module']
askol

Esto lo hizo por mí
Riziero

12
app = Celery('proj',
             broker='amqp://',
             backend='amqp://',
             include=['proj.tasks'])

por favor incluya = ['proj.tasks'] Necesita ir al directorio superior, luego ejecutar esto

celery -A app.celery_module.celeryapp worker --loglevel=info

no

celery -A celeryapp worker --loglevel=info

en sus importaciones de entrada celeryconfig.py = ("path.ptah.tasks",)

por favor en otro módulo invocar tarea !!!!!!!!


1
El includeparámetro debe agregarse si está utilizando importaciones relativas.
Resolví

1
Votó su respuesta para esta cadena please in other module invoke task!!!!!!!!. Eso ayudo.
VolArt

8

El uso de --settings no funcionó para mí. Tuve que usar lo siguiente para que todo funcionara:

celery --config=celeryconfig --loglevel=INFO

Aquí está el archivo celeryconfig que tiene CELERY_IMPORTS agregado:

# Celery configuration file
BROKER_URL = 'amqp://'
CELERY_RESULT_BACKEND = 'amqp://'

CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_TIMEZONE = 'America/Los_Angeles'
CELERY_ENABLE_UTC = True

CELERY_IMPORTS = ("tasks",)

Mi configuración fue un poco más complicada porque estoy usando supervisor para lanzar apio como un demonio.


8

Para mí, este error se resolvió asegurándome de que la aplicación que contiene las tareas se incluyera en la configuración INSTALLED_APPS de django.


Además, las tareas debían ser accesibles desde <app> /tasks.py
np8

3

Este problema surgió misteriosamente cuando agregué un poco de manejo de señales a mi aplicación django. Al hacerlo, convertí la aplicación para usar un AppConfig, lo que significa que en lugar de simplemente leer como 'booking'en INSTALLED_APPS, leyó'booking.app.BookingConfig' .

El apio no entiende lo que eso significa, así que agregué, INSTALLED_APPS_WITH_APPCONFIGS = ('booking',)a mi configuración de django, y modifiqué mi celery.pyde

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

a

app.autodiscover_tasks(
    lambda: settings.INSTALLED_APPS + settings.INSTALLED_APPS_WITH_APPCONFIGS
)

3

Lo que funcionó para mí fue agregar un nombre explícito al decorador de tareas de apio. Cambié mi declaración de tarea de @app.tasksa@app.tasks(name='module.submodule.task')

Aquí hay un ejemplo

# test_task.py
@celery.task
def test_task():
    print("Celery Task  !!!!")

# test_task.py
@celery.task(name='tasks.test.test_task')
def test_task():
    print("Celery Task  !!!!")

2

Tuve el mismo problema al ejecutar tareas desde Celery Beat. Al apio no le gustan las importaciones relativas, así que en mi celeryconfig.py, tuve que establecer explícitamente el nombre completo del paquete:

app.conf.beat_schedule = {
   'add-every-30-seconds': {
        'task': 'full.path.to.add',
        'schedule': 30.0,
        'args': (16, 16)
    },
}

Desearía que los documentos de apio tuvieran más ejemplos con nombres completos de paquetes. Después de ver full.path.to.add en esta respuesta, descubrí que no necesitaba las importaciones. Sabía que la solución era simple y solo necesitaba tener un mejor ejemplo de app.conf.beat_schedule.
zerocog

2

Esto, curiosamente, también puede deberse a que falta un paquete. Ejecute pip para instalar todos los paquetes necesarios: pip install -r requirements.txt

autodiscover_tasks no estaba recogiendo tareas que usaban paquetes faltantes.


1
Tuve un problema similar. Creo que lo que sucede es una excepción durante la importación que hace que partes del descubrimiento automático no se completen.
Tim Tisdall

Ahh sí, tiene sentido. Gracias
kakoma

1

No tuve ningún problema con Django . Pero encontré esto cuando estaba usando Flask . La solución fue configurar la opción de configuración.

celery worker -A app.celery --loglevel=DEBUG --config=settings

mientras que con Django, acabo de tener:

python manage.py celery worker -c 2 --loglevel=info


1

También encontré este problema, pero no es lo mismo, así que solo para tu información. Las actualizaciones recientes provocan este mensaje de error debido a esta sintaxis de decorador.

ERROR/MainProcess] Received unregistered task of type 'my_server_check'.

@task('my_server_check')

Tuvo que cambiar a solo

@task()

No tengo ni idea de por qué.


1

Si está utilizando la configuración de aplicaciones en aplicaciones instaladas como esta:

LOCAL_APPS = [
'apps.myapp.apps.MyAppConfig']

Luego, en su aplicación de configuración, importe la tarea en un método listo como este:

from django.apps import AppConfig

class MyAppConfig(AppConfig):
    name = 'apps.myapp'

    def ready(self):
        try:
            import apps.myapp.signals  # noqa F401
            import apps.myapp.tasks
        except ImportError:
            pass

0

Si se encuentra con este tipo de error, hay varias causas posibles, pero la solución que encontré fue que mi archivo de configuración de celeryd en / etc / defaults / celeryd estaba configurado para uso estándar, no para mi proyecto específico de django. Tan pronto como lo convertí al formato especificado en los documentos de apio , todo estuvo bien.


0

La solución para mí para agregar esta línea a / etc / default / celeryd

CELERYD_OPTS="-A tasks"

Porque cuando ejecuto estos comandos:

celery worker --loglevel=INFO
celery worker -A tasks --loglevel=INFO

Solo el último comando mostraba nombres de tareas.

También intenté agregar la línea CELERY_APP / etc / default / celeryd, pero tampoco funcionó.

CELERY_APP="tasks"

0

Tuve el problema con las clases PeriodicTask en django-celery, mientras que sus nombres aparecieron bien al iniciar el trabajador de apio con cada ejecución desencadenada:

KeyError: u'my_app.tasks.run '

Mi tarea era una clase llamada 'CleanUp', no solo un método llamado 'ejecutar'.

Cuando revisé la tabla 'djcelery_periodictask', vi entradas desactualizadas y eliminarlas solucionó el problema.


0

Solo para agregar mis dos centavos por mi caso con este error ...

Mi camino es /vagrant/devops/testcon app.pyy__init__.py en él.

Cuando corro cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=info , recibo este error.

Pero cuando lo ejecuto como si cd /vagrant/devops/test && celery worker -A app.celery --loglevel=infotodo estuviera bien.


0

Descubrí que uno de nuestros programadores agregó la siguiente línea a una de las importaciones:

os.chdir(<path_to_a_local_folder>)

Esto hizo que el trabajador de Celery cambiara su directorio de trabajo del directorio de trabajo predeterminado de los proyectos (donde podría encontrar las tareas) a un directorio diferente (donde no pudo encontrar las tareas).

Después de eliminar esta línea de código, se encontraron y registraron todas las tareas.


0

El apio no admite importaciones relativas, por lo que en mi celeryconfig.py, necesita una importación absoluta.

CELERYBEAT_SCHEDULE = {
        'add_num': {
            'task': 'app.tasks.add_num.add_nums',
            'schedule': timedelta(seconds=10),
            'args': (1, 2)
        }
}

0

Un elemento adicional a una lista realmente útil.

Encontré que Celery no perdona en relación con los errores en las tareas (o al menos no he podido rastrear las entradas de registro apropiadas) y no las registra. He tenido una serie de problemas con la ejecución de Celery como servicio, que se han relacionado principalmente con permisos.

Lo último relacionado con la escritura de permisos en un archivo de registro. No tuve problemas en el desarrollo ni en la ejecución de apio en la línea de comandos, pero el servicio informó que la tarea no estaba registrada.

Necesitaba cambiar los permisos de la carpeta de registro para permitir que el servicio escribiera en ella.


0

Mis 2 centavos

Obtenía esto en una imagen de Docker usando alpine. La configuración de django a la que se hace referencia /dev/logpara iniciar sesión en syslog. La aplicación de django y el trabajador de apio se basaron en la misma imagen. El punto de entrada de la imagen de la aplicación django se estaba iniciando syslogdal inicio, pero no el del trabajador de apio. Esto estaba causando que cosas como ./manage.py shellfallasen porque no habría ninguna /dev/log. El trabajador del apio no estaba fallando. En cambio, ignoraba silenciosamente el resto del lanzamiento de la aplicación, que incluía cargar shared_taskentradas de aplicaciones en el proyecto django.


0

En mi caso, el error se debió a que un contenedor creó archivos en una carpeta que se montaron en el sistema de archivos del host con docker-compose.

Solo tenía que eliminar los archivos creados por el contenedor en el sistema host y pude lanzar mi proyecto nuevamente.

sudo rm -Rf nombre de carpeta

(Tuve que usar sudo porque los archivos eran propiedad del usuario root)

Versión de Docker: 18.03.1


0

Si lo usa autodiscover_tasks, asegúrese de que su functionsregistro permanezca en el tasks.py, no en ningún otro archivo. O el apio no puede encontrar elfunctions que desea registrar.

Utilizar app.register_task también servirá, pero parece un poco ingenuo.

Consulte esta especificación oficial de autodiscover_tasks.

def autodiscover_tasks(self, packages=None, related_name='tasks', force=False):
    """Auto-discover task modules.

    Searches a list of packages for a "tasks.py" module (or use
    related_name argument).

    If the name is empty, this will be delegated to fix-ups (e.g., Django).

    For example if you have a directory layout like this:

    .. code-block:: text

        foo/__init__.py
           tasks.py
           models.py

        bar/__init__.py
            tasks.py
            models.py

        baz/__init__.py
            models.py

    Then calling ``app.autodiscover_tasks(['foo', bar', 'baz'])`` will
    result in the modules ``foo.tasks`` and ``bar.tasks`` being imported.

    Arguments:
        packages (List[str]): List of packages to search.
            This argument may also be a callable, in which case the
            value returned is used (for lazy evaluation).
        related_name (str): The name of the module to find.  Defaults
            to "tasks": meaning "look for 'module.tasks' for every
            module in ``packages``."
        force (bool): By default this call is lazy so that the actual
            auto-discovery won't happen until an application imports
            the default modules.  Forcing will cause the auto-discovery
            to happen immediately.
    """

0

Escriba la ruta correcta a las tareas del archivo

app.conf.beat_schedule = {
'send-task': {
    'task': 'appdir.tasks.testapp',
    'schedule': crontab(minute='*/5'),  
},

}


0

al ejecutar el apio con el comando "celery -A conf worker -l info", todas las tareas se enumeran en el registro como yo. conf.celery.debug_task Recibí el error porque no estaba dando esta ruta de tarea exacta. Así que, por favor, vuelva a comprobar esto copiando y pegando la identificación exacta de la tarea.


0
app = Celery(__name__, broker=app.config['CELERY_BROKER'], 
backend=app.config['CELERY_BACKEND'], include=['util.xxxx', 'util.yyyy'])

0

La respuesta a sus mentiras de problemas en la primera línea de la salida que ya ha proporcionado en su pregunta: /usr/local/lib/python2.7/dist-packages/celery/loaders/default.py:64: NotConfigured: No 'celeryconfig' module found! Please make sure it exists and is available to Python. "is available to Python." % (configname, ))). Sin la configuración correcta, Celery no puede hacer nada.

La razón por la que no puede encontrar la configuración de apio es muy probable que no esté en su PYTHONPATH.


0

He resuelto mi problema, mi 'tarea' está en un paquete de Python llamado 'celery_task', cuando salgo de este paquete y ejecuto el comando celery worker -A celery_task.task --loglevel=info. Funciona.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.