web-dev-qa-db-fra.com

Celery AttributeError: erreur async

RabbitMQ et Celery s'exécutant localement sur mon Mac (OS/X 10.13.4), le code suivant fonctionne localement lorsque j'exécute add.delay (x, y):

#!/usr/bin/env python
from celery import Celery
from celery.utils.log import get_task_logger

logger = get_task_logger(__name__)

app = Celery('tasks', \
        broker='pyamqp://appuser:xx@c2/appvhost', \
        backend='db+mysql://appuser:xx@c2/pigpen')

@app.task(bind=True)
def dump_context(self, x, y):
    print('Executing task id {0.id}, args: {0.args!r} kwargs {0.kwargs!r}'.format(self.request))

@app.task
def add(x, y):
    logger.info('Adding {0} + {1}'.format(x, y))
    return x + y

Cependant, lorsque j'essaie d'exécuter le travailleur Celery sur un serveur ODROID-C2 exécutant Kali 2018.2 (avec les mises à jour actuelles), l'erreur suivante s'affiche lors de l'exécution de celery -A tasks worker --loglevel=info:

Traceback (most recent call last):
  File "/usr/local/bin/celery", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/celery/__main__.py", line 14, in main
    _main()
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 326, in main
    cmd.execute_from_commandline(argv)
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 488, in execute_from_commandline
    super(CeleryCommand, self).execute_from_commandline(argv)))
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/base.py", line 281, in execute_from_commandline
    return self.handle_argv(self.prog_name, argv[1:])
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 480, in handle_argv
    return self.execute(command, argv)
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 412, in execute
    ).run_from_argv(self.prog_name, argv[1:], command=argv[0])
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/worker.py", line 221, in run_from_argv
    return self(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/base.py", line 244, in __call__
    ret = self.run(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/celery/bin/worker.py", line 255, in run
    **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 99, in __init__
    self.setup_instance(**self.prepare_args(**kwargs))
  File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 122, in setup_instance
    self.should_use_eventloop() if use_eventloop is None
  File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 241, in should_use_eventloop
    self._conninfo.transport.implements.async and
  File "/home/autossh/.local/lib/python2.7/site-packages/kombu/transport/base.py", line 125, in __getattr__
    raise AttributeError(key)
AttributeError: async

De Kali ODROID, je peux me connecter à l’instance RabbitMQ de l’hôte nommé c2 à l’aide d’un script Python Pika et mysql de ce périphérique fonctionne également sur la machine c2. J'ai trouvé des erreurs similaires, aucune de ces solutions n'a fonctionné pour moi.

La version de céleri installée sur l’ODROID-C2 via pip est la suivante:

celery --version
4.1.0 (latentcall)
pythoncelerycelery-task
52
DYoung

Nous avons trié par mise à jour céleri == 4.1.1

il semble que la dernière version de la 4.1.X ait réglé le changement de nom de module sur kombu

82
shipperizer

Assurez-vous que vous utilisez Kombu 4.1.0. La dernière version de Kombu renomme async en asynchrone.

24
ryanmehta

Le céleri n'épingle pas ses exigences pour le kombu et le billard à des versions spécifiques. Ils nécessitent les éléments suivants:

billiard>=3.5.0.2,<3.6.0
kombu>=4.0.2,<5.0

https://github.com/celery/celery/blob/v4.1.0/requirements/default.txt

kombu 4.2.0 a été publié avec une modification radicale et les versions précédentes de celery l'installent automatiquement.

Etant donné que le céleri n'épingle pas des versions spécifiques, vous devez épingler les éléments suivants si vous continuez à utiliser céleri 4.1.0:

kombu==4.1.0
billiard==3.5.0.2
12
John

pip install --upgrade 'celery>=4.2.0rc4'

kombu==4.2.0 renomme async en asynchronous, le céleri l'a corrigé dans celery==4.2.0rc4.

Donc, vous devriez mettre à jour le céleri à 4.2.0rc4.

voir: https://github.com/celery/celery/commit/c8ef7ad60b72a194654c58beb04a1d65cd0435ad

7
吴毅凡

C'était le problème, c'était en fait la version kombu.

J'ai réussi à installer 2 versions de kombu, 4.2.0 en tant qu'utilisateur 'appuser', que j'essayais de démarrer le travailleur sous, et 4.1.0 en tant que 'root'. Le 4.1.0 en tant que 'root' fonctionnerait, mais pas l’autre utilisateur.

J'ai supprimé kombu 4.2.0 du compte utilisateur 'appuser'(pincez désinstaller kombu en tant qu'utilisateur), afin qu'il utilise le package installé à l'échelle du système et que le serveur Celery a fonctionné correctement sous ce compte.

Pour vérifier que c’est bien kombu 4.2.0 qui se casse, j’ai supprimé la version 4.1.0 pour l’ensemble du système et laissé pip installer la dernière version, qu’il obtient en tant que version 4.2.0, et l’agent de céleri ne plus démarrer Je l'ai désinstallé et j'ai forcé pip à installer 4.1.0 (pip install kombu == 4.1.0) et l'opérateur a fonctionné correctement.

Comme autre vérification, je suis allé sur mon Mac, où j’ai écrit/testé ce code et j’ai vérifié la version de kombu installée à l’aide du pip: 4.1.0. Je ne sais pas pourquoi pip sur le Mac et Pi3 ont installé la version 4.1.0 de kombu alors que pip sur l’ODROID-C2 a installé la version 4.2.0. Je vais creuser plus si j'ai une chance mais ça fonctionne maintenant.

6
DYoung

Un correctif rapide de hack consiste à désactiver le résultat final:

# CELERY_RESULT_BACKEND = 'redis://redis'
0
jmoz