Céleri a reçu une tâche non enregistrée de type (exemple d'exécution)

J'essaye d'exécuter l' exemple de la documentation Celery.

Je cours: 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

tâches.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())

Dans le même dossier celeryconfig.py:

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

Lorsque j'exécute "run_task.py":

sur console python

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

erreurs sur le serveur 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'

Veuillez expliquer quel est le problème.

Vous pouvez voir la liste actuelle des tâches enregistrées dans la celery.registry.TaskRegistryclasse. Peut-être que votre celeryconfig (dans le répertoire courant) n'est pas dans, PYTHONPATHdonc céleri ne peut pas le trouver et revient aux valeurs par défaut. Spécifiez-le simplement explicitement lors du démarrage du céleri.

celeryd --loglevel=INFO --settings=celeryconfig

Vous pouvez également définir --loglevel=DEBUGet vous devriez probablement voir le problème immédiatement.

Je pense que vous devez redémarrer le serveur de travail. Je rencontre le même problème et je le résolve en redémarrant.

J'ai eu le même problème: la raison en "Received unregistered task of type.."était que le service celeryd n'a pas trouvé et enregistré les tâches au démarrage du service (btw leur liste est visible lorsque vous démarrez ./manage.py celeryd --loglevel=info).

Ces tâches doivent être déclarées dans le CELERY_IMPORTS = ("tasks", )fichier de paramètres.
Si vous avez un celery_settings.pyfichier spécial , il doit être déclaré au démarrage du service --settings=celery_settings.pyceleryd comme l'a écrit digivampire.

Que vous utilisiez CELERY_IMPORTSou autodiscover_tasks, le point important est que les tâches peuvent être trouvées et que le nom des tâches enregistrées dans Celery doit correspondre aux noms que les travailleurs tentent de récupérer.

Lorsque vous lancez le céleri, par exemple celery worker -A project --loglevel=DEBUG, vous devriez voir le nom des tâches. Par exemple, si j'ai une debug_tasktâche dans mon 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 vous ne pouvez pas voir vos tâches dans la liste, s'il vous plaît vérifier vos importations de configuration de céleri les tâches correctement, que ce soit dans --setting, --config, celeryconfigou config_from_object.

Si vous utilisez un battement de céleri, assurez-vous que le nom de la tâche,, que taskvous utilisez CELERYBEAT_SCHEDULEcorrespond au nom de la liste des tâches de céleri.

J'ai aussi eu le même problème; J'ai ajouté

CELERY_IMPORTS=("mytasks")

dans mon celeryconfig.pydossier pour le résoudre.

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

please include = ['proj.tasks'] Vous devez aller dans le répertoire supérieur, puis exécuter ceci

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

ne pas

celery -A celeryapp worker --loglevel=info

dans votre entrée celeryconfig.py importations = ("path.ptah.tasks",)

s'il vous plaît dans un autre module invoquer la tâche !!!!!!!!

L'utilisation de --settings n'a pas fonctionné pour moi. J'ai dû utiliser ce qui suit pour que tout fonctionne:

celery --config=celeryconfig --loglevel=INFO

Voici le fichier celeryconfig qui a le CELERY_IMPORTS ajouté:

# 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",)

Ma configuration était un peu plus délicate car j'utilise un superviseur pour lancer le céleri en tant que démon.

Pour moi, cette erreur a été résolue en s'assurant que l'application contenant les tâches était incluse dans le paramètre INSTALLED_APPS de django.

J'ai eu ce problème mystérieusement survenu lorsque j'ai ajouté une gestion du signal à mon application django. Ce faisant, j'ai converti l'application pour qu'elle utilise un AppConfig, ce qui signifie qu'au lieu de simplement lire comme 'booking'inINSTALLED_APPS , il a lu 'booking.app.BookingConfig'.

Celery ne comprend pas ce que cela signifie, alors j'ai ajouté, INSTALLED_APPS_WITH_APPCONFIGS = ('booking',)à mes paramètres django, et modifié mon celery.pydepuis

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

à

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

Ce qui a fonctionné pour moi, a été d'ajouter un nom explicite au décorateur de tâches de céleri. J'ai changé ma déclaration de tâche de @app.tasksà@app.tasks(name='module.submodule.task')

Voici un exemple

# 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  !!!!")

J'ai eu le même problème lors de l'exécution des tâches de Celery Beat. Celery n'aime pas les importations relatives, donc dans mon celeryconfig.py, j'ai dû définir explicitement le nom complet du package:

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

Ceci, étrangement, peut aussi être dû à un paquet manquant. Exécutez pip pour installer tous les packages nécessaires: pip install -r requirements.txt

autodiscover_tasks ne prenait pas en charge les tâches qui utilisaient des packages manquants.

Je n'ai eu aucun problème avec Django . Mais j'ai rencontré cela lorsque j'utilisais Flask . La solution était de définir l'option de configuration.

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

tandis qu'avec Django, je viens d'avoir:

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

J'ai également rencontré ce problème, mais ce n'est pas tout à fait le même, donc juste pour info. Les mises à niveau récentes provoquent ce message d'erreur en raison de cette syntaxe de décorateur.

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

@task('my_server_check')

Doit être changé pour juste

@task()

Aucune idée pourquoi.

Si vous utilisez la configuration des applications dans des applications installées comme celle-ci:

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

Ensuite, dans votre application de configuration, importez la tâche dans la méthode prête comme ceci:

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

Si vous rencontrez ce type d'erreur, il existe un certain nombre de causes possibles, mais la solution que j'ai trouvée était que mon fichier de configuration celeryd dans / etc / defaults / celeryd était configuré pour une utilisation standard, pas pour mon projet django spécifique. Dès que je l'ai converti au format spécifié dans les documents sur le céleri , tout allait bien.

La solution pour moi d'ajouter cette ligne à / etc / default / celeryd

CELERYD_OPTS="-A tasks"

Parce que quand j'exécute ces commandes:

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

Seule la dernière commande affichait des noms de tâches.

J'ai également essayé d'ajouter la ligne CELERY_APP / etc / default / celeryd mais cela n'a pas fonctionné non plus.

CELERY_APP="tasks"

J'ai eu le problème avec les classes PeriodicTask dans django-celery, alors que leurs noms apparaissaient bien lors du démarrage du céleri à chaque exécution déclenchée:

KeyError: u'my_app.tasks.run '

Ma tâche était une classe nommée «CleanUp», pas seulement une méthode appelée «run».

Lorsque j'ai vérifié la table 'djcelery_periodictask', j'ai vu des entrées obsolètes et leur suppression a résolu le problème.

Juste pour ajouter mes deux cents pour mon cas avec cette erreur ...

Mon chemin est /vagrant/devops/testavec app.pyet__init__.py dedans.

Quand je cours cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=info , j'obtiens cette erreur.

Mais quand je le lance comme si cd /vagrant/devops/test && celery worker -A app.celery --loglevel=infotout allait bien.

J'ai constaté que l'un de nos programmeurs a ajouté la ligne suivante à l'une des importations:

os.chdir(<path_to_a_local_folder>)

Cela a amené l'ouvrier Celery à changer son répertoire de travail du répertoire de travail par défaut des projets (où il pouvait trouver les tâches) vers un autre répertoire (où il ne pouvait pas trouver les tâches).

Après avoir supprimé cette ligne de code, toutes les tâches ont été trouvées et enregistrées.

Le céleri ne prend pas en charge les importations relatives, donc dans mon celeryconfig.py, vous avez besoin d'une importation absolue.

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

Un élément supplémentaire à une liste vraiment utile.

J'ai trouvé Celery impitoyable en ce qui concerne les erreurs dans les tâches (ou du moins je n'ai pas été en mesure de retracer les entrées de journal appropriées) et il ne les enregistre pas. J'ai eu un certain nombre de problèmes avec l'exécution de Celery en tant que service, qui étaient principalement liés aux autorisations.

La dernière concernant les autorisations d'écriture dans un fichier journal. Je n'ai eu aucun problème de développement ou d'exécution de céleri sur la ligne de commande, mais le service a signalé la tâche comme non enregistrée.

J'avais besoin de modifier les autorisations du dossier de journal pour permettre au service d'y écrire.

Mes 2 cents

J'obtenais cela dans une image de docker en utilisant alpin. Les paramètres de django référencés /dev/logpour la journalisation dans syslog. L'application django et le céleri worker étaient tous deux basés sur la même image. Le point d'entrée de l'image de l'application django se lancait syslogdau démarrage, mais celui du céleri ne l'était pas. Cela faisait ./manage.py shelléchouer les choses parce qu'il n'y en aurait pas /dev/log. Le céleri-ouvrier n'échouait pas. Au lieu de cela, il ignorait silencieusement le reste du lancement de l'application, qui comprenait le chargement d' shared_taskentrées à partir d'applications dans le projet django

Dans mon cas, l'erreur était due au fait qu'un conteneur avait créé des fichiers dans un dossier qui étaient montés sur le système de fichiers hôte avec docker-compose.

Je devais simplement supprimer les fichiers créés par le conteneur sur le système hôte et j'ai pu relancer mon projet.

sudo rm -Rf nom du dossier

(J'ai dû utiliser sudo car les fichiers appartenaient à l'utilisateur root)

Version Docker: 18.03.1

Si vous utilisez autodiscover_tasks, assurez-vous que votre functionsinscription reste dans le tasks.pyfichier, pas dans un autre fichier. Ou le céleri ne peut pas trouver lefunctions vous souhaitez enregistrer.

Utilisation app.register_task fera également l'affaire, mais semble un peu naïf.

Veuillez vous référer à cette spécification officielle 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.
    """

Écrivez le chemin correct vers les tâches de fichier

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

}

lors de l'exécution du céleri avec la commande "céleri -A conf worker -l info", toutes les tâches ont été répertoriées dans le journal comme je l'avais. conf.celry.debug_task J'obtenais l'erreur parce que je ne donnais pas ce chemin exact de tâche. Veuillez donc revérifier cela en copiant et en collant l'identifiant exact de la tâche.

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

La réponse à votre problème réside dans LA PREMIÈRE LIGNE du résultat que vous avez fourni dans votre question: /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, ))) . Sans la bonne configuration, Celery ne peut rien faire.

La raison pour laquelle il ne trouve pas le celeryconfig est très probablement qu'il ne se trouve pas dans votre PYTHONPATH.

J'ai résolu mon problème, ma 'tâche' est sous un paquet python nommé 'celery_task' ， quand je quitte ce paquet et exécute la commande celery worker -A celery_task.task --loglevel=info. Ça marche.