Céleri Tâche de type non enregistrée reçue (exemple d'exécution)
J'essaie de lancer exemple à partir de la documentation Celery.
Je lance: 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())
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
Quand je lance "run_task.py":
sur une 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'
S'il vous plaît expliquer quel est le problème.
Vous pouvez voir la liste actuelle des tâches enregistrées dans la classe celery.registry.TaskRegistry. Il se peut que votre celeryconfig (dans le répertoire en cours) ne soit pas dans PYTHONPATH. Le céleri ne peut donc pas le trouver et revient aux valeurs par défaut. Spécifiez-le simplement explicitement au démarrage du céleri.
celeryd --loglevel=INFO --settings=celeryconfig
Vous pouvez également définir --loglevel=DEBUG et vous devriez probablement voir le problème immédiatement.
J'ai eu le même problème: La raison de "Received unregistered task of type.." était que le service celeryd n'avait pas trouvé et enregistré les tâches au démarrage du service (leur liste est visible lorsque vous démarrez ./manage.py celeryd --loglevel=info).
Ces tâches doivent être déclarées dans CELERY_IMPORTS = ("tasks", ) dans le fichier de paramètres.
Si vous avez un fichier celery_settings.py spécial, il doit être déclaré sur le service celeryd comme suit: --settings=celery_settings.py, comme l'a écrit digivampire.
Je pense que vous devez redémarrer le serveur de travail. Je rencontre le même problème et le résout en le redémarrant.
Que vous utilisiez CELERY_IMPORTS ou autodiscover_tasks, le point important est que les tâches puissent être trouvées et que le nom des tâches enregistrées dans Celery doit correspondre aux noms que les opérateurs tentent d'extraire.
Lorsque vous lancez le céleri, dites celery worker -A project --loglevel=DEBUG, vous devriez voir le nom des tâches. Par exemple, si j'ai une tâche debug_task 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 voyez pas vos tâches dans la liste, vérifiez que votre configuration de céleri les importe correctement, que ce soit en --setting, --config, celeryconfig ou config_from_object.
Si vous utilisez le temps de céleri, assurez-vous que le nom de la tâche, task, que vous utilisez dans CELERYBEAT_SCHEDULE correspond au nom figurant dans la liste des tâches du céleri.
J'ai aussi eu le même problème; J'ai ajouté
CELERY_IMPORTS=("mytasks")
dans mon fichier celeryconfig.py pour le résoudre.
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.
Utiliser --settings n'a pas fonctionné pour moi. J'ai dû utiliser les éléments suivants pour que tout fonctionne:
celery --config=celeryconfig --loglevel=INFO
Voici le fichier celeryconfig auquel CELERY_IMPORTS a été 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 compliquée car j'utilise supervisor pour lancer le céleri en tant que démon.
app = Celery('proj',
broker='amqp://',
backend='amqp://',
include=['proj.tasks'])
s'il vous plaît inclure = ['proj.tasks'] Vous devez aller dans le répertoire principal
celery -A app.celery_module.celeryapp worker --loglevel=info
ne pas
celery -A celeryapp worker --loglevel=info
dans votre celeryconfig.py input imports = ("path.ptah.tasks",)
s'il vous plaît dans une autre tâche d'invocation de module !!!!!!!!
J'ai eu ce problème mystérieusement surgi lorsque j'ai ajouté une certaine gestion du signal à mon application Django. Ce faisant, j'ai converti l'application pour qu'elle utilise AppConfig, ce qui signifie qu'au lieu de lire simplement 'booking 'dans INSTALLED_APPS, elle lisait 'booking.app.BookingConfig'.
Le céleri ne comprend pas ce que cela signifie, alors j’ai ajouté INSTALLED_APPS_WITH_APPCONFIGS = ('booking',) à mes paramètres Django et modifié mon celery.py de
app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)
à
app.autodiscover_tasks(
lambda: settings.INSTALLED_APPS + settings.INSTALLED_APPS_WITH_APPCONFIGS
)
Bizarrement, cela 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 récupérait pas les tâches qui utilisaient des packages manquants.
J'ai eu le même problème en exécutant des tâches de Celery Beat. Le céleri n'aime pas les importations relatives. Dans mon celeryconfig.py, je devais donc définir explicitement le nom complet du paquet:
app.conf.beat_schedule = {
'add-every-30-seconds': {
'task': 'full.path.to.add',
'schedule': 30.0,
'args': (16, 16)
},
}
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 !!!!")
Je n'ai eu aucun problème avec Django . Mais rencontré ceci quand j'utilisais Flask . La solution était de définir l'option de configuration.
celery worker -A app.celery --loglevel=DEBUG --config=settings
avec Django, je viens d'avoir:
python manage.py celery worker -c 2 --loglevel=info
Si vous rencontrez ce type d'erreur, il existe plusieurs causes possibles, mais la solution que j'ai trouvée était que mon fichier de configuration céleryd 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 la documentation 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 cette 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"
Un élément supplémentaire à une liste vraiment utile.
J'ai trouvé que Celery ne pardonnait pas en raison d'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. L'exécution de Celery en tant que service pose un certain nombre de problèmes, principalement liés aux autorisations.
La dernière en date concerne les autorisations écrivant dans un fichier journal. Je n’ai eu aucun problème de développement ou d’exécution du céleri sur la ligne de commande, mais le service a signalé que la tâche n’était pas enregistrée.
Je devais modifier les autorisations du dossier de journal pour permettre au service d'y écrire.
La réponse à votre problème réside dans LA PREMIÈRE LIGNE de la sortie que vous avez fournie 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, le céleri ne peut rien faire.
La raison pour laquelle il ne peut pas trouver le céleri-config est probablement qu'elle ne se trouve pas dans votre PYTHONPATH.
J'ai résolu mon problème, ma 'tâche' se trouve dans un package python nommé 'celery_task' lorsque je quitte ce package et exécute la commande celery worker -A celery_task.task --loglevel=info. Ça marche.
Écrire le chemin correct pour les tâches de fichier
app.conf.beat_schedule = {
'send-task': {
'task': 'appdir.tasks.testapp',
'schedule': crontab(minute='*/5'),
},
}
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é le travailleur de céleri à changer son répertoire de travail du répertoire de travail par défaut des projets (où il pouvait trouver les tâches) à 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.
Juste pour ajouter mes deux cents pour mon cas avec cette erreur ...
Mon chemin est /vagrant/devops/test avec app.py et __init__.py dedans.
Lorsque je lance cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=info, j'obtiens cette erreur.
Mais quand je le lance comme cd /vagrant/devops/test && celery worker -A app.celery --loglevel=info, tout va bien.
lors de l'exécution du céleri avec la commande "céleri - Un ouvrier - Info", toutes les tâches ont été répertoriées dans le journal comme si j'avais eu. conf.celery.debug_task je recevais l'erreur parce que je ne donnais pas ce chemin de tâche exact. Donc, revérifier ceci en copiant et en collant l'identifiant exact de la tâche.
Dans mon cas, l'erreur est due au fait qu'un conteneur a créé des fichiers dans un dossier qui ont été montés sur le système de fichiers hôte avec docker-compose.
Il me suffisait de supprimer les fichiers créés par le conteneur sur le système hôte et j'ai pu relancer mon projet.
Sudo rm -Rf nomdossier
(J'ai dû utiliser Sudo car les fichiers appartenaient à l'utilisateur root)
Version de Docker: 18.03.1
Le céleri ne prenant pas en charge les importations relatives, vous devez donc effectuer une importation absolue dans mon célericonfig.py.
CELERYBEAT_SCHEDULE = {
'add_num': {
'task': 'app.tasks.add_num.add_nums',
'schedule': timedelta(seconds=10),
'args': (1, 2)
}
}
Mes 2 centimes
Je devenais cela dans une image de docker en utilisant Alpine. Les paramètres Django référencés /dev/log pour se connecter à syslog. L'application Django et la travailleuse du céleri étaient toutes deux basées sur la même image. Le point d’entrée de l’image d’application Django était le lancement de syslogd au début, mais pas celui destiné au céleri-rave. Cela entraînait l'échec de choses comme ./manage.py Shell car il n'y aurait pas de /dev/log. La travailleuse de céleri n'échouait pas. Au lieu de cela, il ignorait silencieusement le reste du lancement de l'application, qui comprenait le chargement d'entrées shared_task à partir d'applications dans le projet Django
Le céleri n'importera pas la tâche si l'application manquait de certaines de ses dépendances. Par exemple, une application.view importe numpy sans l'avoir installée. Le meilleur moyen de vérifier cela est d’essayer d’exécuter votre serveur Django, comme vous le savez probablement:
python manage.py runserver
Vous avez trouvé le problème si cela pose ImportErrors dans l'application hébergeant la tâche respective. Il suffit de pip tout installer, ou essayez de supprimer les dépendances et essayez à nouveau. Ce n'est pas la cause de votre problème autrement.
J'ai eu le problème avec les classes PeriodicTask dans Django-celery, alors que leurs noms se présentaient bien au démarrage de l'ouvreur du céleri à chaque exécution:
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 les supprimer a corrigé le problème.
app = Celery(__name__, broker=app.config['CELERY_BROKER'],
backend=app.config['CELERY_BACKEND'], include=['util.xxxx', 'util.yyyy'])
Si vous utilisez autodiscover_tasks, assurez-vous que votre functions à enregistrer reste dans le tasks.py et non dans un autre fichier. Ou le céleri ne peut pas trouver la functions que vous souhaitez enregistrer.
Utiliser app.register_task fera aussi le travail, 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.
"""