and - python celery redis

Apio Se recibió una tarea de tipo no registrada(ejemplo de ejecución)

Question

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

Yo 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

tareas.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 apio

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

Por favor explique cuál es el problema.

Answer 1

Creo que necesitas reiniciar el servidor de trabajo. Me encuentro con el mismo problema y lo resuelvo reiniciando.

Answer 2

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

os.chdir(<path_to_a_local_folder>)

Esto provocó 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, todas las tareas fueron encontradas y registradas.

Answer 3

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

Answer 4

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

celery --config=celeryconfig --loglevel=INFO

Aquí está el archivo celeryconfig que tiene el 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 demonio.

Answer 5

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 la ventana acoplable compuesta.

Solo tuve que eliminar los archivos creados por el contenedor en el sistema host y pude iniciar mi proyecto nuevamente.

sudo rm -Rf nombre de carpeta

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

Versión Docker: 18.03.1

Answer 6

Esto, extrañamente, también puede ser debido a un paquete faltante. Ejecute pip para instalar todos los paquetes necesarios: pip install -r requirements.txt

autodiscover_tasks no estaba recogiendo tareas que usaban paquetes faltantes.

Answer 7

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

Sólo el último comando mostraba nombres de tareas.

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

CELERY_APP="tasks"

Answer 8

Lo que funcionó para mí fue agregar un nombre explícito al decorador de apio. Cambié mi declaración de tarea de @app.tasks a @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  !!!!")

Answer 9

Mis 2 centavos

Estaba obteniendo esto en una imagen docker usando alpine. La configuración de django hace referencia a /dev/log para el registro en syslog. La aplicación django y el trabajador del apio se basaron en la misma imagen. El punto de entrada de la imagen de la aplicación django fue el inicio de syslogd en el inicio, pero el del apio no lo fue. Esto estaba causando que el ./manage.py shell fallara porque no habría ningún /dev/log . El trabajador del apio no estaba fallando. En su lugar, fue silencioso simplemente ignorando el resto del lanzamiento de la aplicación, que incluía la carga de entradas shared_task desde aplicaciones en el proyecto django.

Answer 10

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

Answer 11

Para mí, este error se resolvió asegurando que la aplicación que contenía las tareas se incluyera en la configuración INSTALLED_APPS de django.

Answer 12

Puede ver la lista actual de tareas registradas en la clase celery.registry.TaskRegistry . Podría ser que su apio (en el directorio actual) no está en PYTHONPATH por lo que el apio no puede encontrarlo y vuelve a los valores predeterminados. Simplemente especifíquelo explícitamente al iniciar el apio.

celeryd --loglevel=INFO --settings=celeryconfig

También puede configurar --loglevel=DEBUG y probablemente debería ver el problema inmediatamente.

Answer 13

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

Answer 14

Si usa autodiscover_tasks , asegúrese de que sus functions para registrarse permanezcan en el tasks.py , no en ningún otro archivo. O el apio no puede encontrar las functions que desea registrar.

Usar app.register_task también hará el trabajo, pero parece un poco ingenuo.

Por favor, 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.
    """

Answer 15

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

Mi ruta es /vagrant/devops/test con app.py y __init__.py en ella.

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

Pero cuando lo ejecuto como cd /vagrant/devops/test && celery worker -A app.celery --loglevel=info todo está bien.

Answer 16

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

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

@task(''my_server_check'')

Había que cambiar a solo

@task()

No hay idea de por qué.

Answer 17

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

CELERY_IMPORTS=("mytasks")

en mi archivo celeryconfig.py para resolverlo.

Answer 18

Tuve el mismo problema ejecutando tareas de 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)
    },
}

Answer 19

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

Estas tareas deben declararse en CELERY_IMPORTS = ("tasks", ) en el archivo de configuración.
Si tiene un archivo especial celery_settings.py , debe declararlo en el servicio celeryd start como --settings=celery_settings.py como escribió Digivampire.

Answer 20

Tuve el problema con las clases de PeriodicTask en django-apio, mientras que sus nombres aparecían bien al iniciar al trabajador de apio 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 verifiqué la tabla ''djcelery_periodictask'', vi entradas obsoletas y al eliminarlas se solucionó el problema.

Answer 21

Tuve un problema que surgió misteriosamente cuando agregué algo 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 , decía ''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.py desde

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

a

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

Answer 22

Un elemento adicional a una lista realmente útil.

He encontrado 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 un servicio, que han estado relacionados principalmente con los permisos.

Lo último relacionado con la escritura de permisos en un archivo de registro. No tuve problemas en el desarrollo o en la ejecución del 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 escriba en él.

Answer 23

Ya sea que use CELERY_IMPORTS o autodiscover_tasks , el punto importante es que las tareas se pueden encontrar y el nombre de las tareas registradas en Apio debe coincidir con los nombres que los trabajadores intentan obtener.

Cuando inicie Celery, diga celery worker -A project --loglevel=DEBUG , debería ver el nombre de las tareas. Por ejemplo, si tengo una tarea debug_task 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, verifique que su configuración de apio importe las tareas correctamente, ya sea en --setting , --config , celeryconfig o config_from_object .

Si está usando apio, asegúrese de que el nombre de la tarea, task que usa en CELERYBEAT_SCHEDULE coincida con el nombre en la lista de tareas de apio.

Answer 24

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

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

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

no

celery -A celeryapp worker --loglevel=info

en su entrada celeryconfig.py imports = ("path.ptah.tasks",)

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