Tipo de tarefa não registrada recebida de aipo (exemplo de execução)


95

Estou tentando executar um exemplo da documentação do Celery.

Eu 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())

Na mesma pasta celeryconfig.py:

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

Quando executo "run_task.py":

no console python

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

erros no servidor 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 qual é o problema.


12
Olá, você poderia compartilhar qual era o problema e como você o resolveu? A resposta aceita não deixa claro como outras pessoas poderiam resolver esse problema. Obrigado.
Jordan Reiter,

3
Estou com Jordan - isso não foi útil em nada. Votos negativos.
Jay Taylor

2
a resposta de aiho é a correta:CELERY_IMPORTS = ("tasks", )
Alp

Respostas:


49

Você pode ver a lista atual de tarefas registradas na celery.registry.TaskRegistryclasse. Pode ser que seu celeryconfig (no diretório atual) não esteja em, PYTHONPATHentão o aipo não pode localizá-lo e voltar aos padrões. Basta especificar explicitamente ao iniciar o aipo.

celeryd --loglevel=INFO --settings=celeryconfig

Você também pode definir --loglevel=DEBUGe provavelmente verá o problema imediatamente.


4
1 para --loglevel=DEBUG, ocorreu um erro de sintaxe na minha tarefa.
Jacob Valenta

11
o aipo está obsoleto. Agora deve-se executar, celery workerpor exemplo, para Djangoassimcelery --app=your_app.celery worker --loglevel=info
andilabs

Para mim (aipo 3.1.23), tive que usar celery.registry.taskspara ver uma lista de todas as minhas tarefas atuais. Você sempre pode verificar executando dir(celery.registry).
Nick Brady

para --loglevel=DEBUGdo meu lado também
Sobi

64

Acho que você precisa reiniciar o servidor de trabalho. Encontro o mesmo problema e resolvo reiniciando.


8
Obrigado! Gostaria de ter encontrado isto há uma hora
Nexus

2
Isso consertou para mim. Se você estiver usando scripts celeryd, o trabalhador importará seu (s) módulo (s) de tarefa na inicialização. Mesmo se você criar mais funções de tarefa ou alterar as existentes, o trabalhador usará suas cópias na memória como estavam quando as leu.
Mark

1
Nota: você pode verificar se suas tarefas estão ou não registradas executandocelery inspect registered
Nick Brady

1
Você também pode iniciar o aipo com a opção --autoreloadque irá reiniciar o aipo cada vez que o código for alterado.
Sergey Lyapustin

Infelizmente obsoleto. Pode-se usar uma solução neste link: avilpage.com/2017/05/…
Tomasz Szkudlarek

50

Eu tive o mesmo problema: O motivo "Received unregistered task of type.."disso foi que o serviço celeryd não encontrou e registrou as tarefas no início do serviço (aliás, a lista deles fica visível quando você inicia ./manage.py celeryd --loglevel=info).

Essas tarefas devem ser declaradas no CELERY_IMPORTS = ("tasks", )arquivo de configurações.
Se você tem um especialcelery_settings.py arquivo ele deve ser declarado no início do serviço --settings=celery_settings.pyceleryd conforme digivampire escreveu.


1
Obrigado, na verdade tive o problema porque comecei a usar o aipo usando ~ / path / to / celery / celeryd em vez de usar o comando manage.py!
Antoine

27

Se você usa CELERY_IMPORTSouautodiscover_tasks , o importante é que as tarefas podem ser encontradas e o nome das tarefas registradas no Celery deve corresponder aos nomes que os trabalhadores tentam buscar.

Quando você inicia o Celery, digamos celery worker -A project --loglevel=DEBUG, você deve ver o nome das tarefas. Por exemplo, se eu tiver uma debug_tasktarefa em meu 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

Se você não pode ver as suas tarefas na lista, por favor, verifique suas importações de configuração aipo as tarefas corretamente, seja em --setting, --config, celeryconfigou config_from_object.

Se você estiver usando a batida de aipo, certifique-se de que o nome da tarefa,, taskvocê usa em CELERYBEAT_SCHEDULEcorresponde ao nome na lista de tarefas de aipo.


Isso foi muito útil. O nome da tarefa deve corresponder à chave 'tarefa' em seu CELERYBEAT_SCHEDULE
ss_millionaire

* O importante é que as tarefas podem ser encontradas e o nome das tarefas registradas no Celery deve coincidir com os nomes que os trabalhadores tentam buscar. * Bom ponto !!!
Light.G

Essa é a resposta correta. O nome da sua tarefa no BEAT_SCHEDULER deve corresponder ao que aparece na lista de tarefas descobertas automaticamente. Então, se você usou @task(name='check_periodically'), ele deve corresponder ao que você colocou na programação de batida, ou seja:CELERY_BEAT_SCHEDULE = { 'check_periodically': { 'task': 'check_periodically', 'schedule': timedelta(seconds=1) }
Mórmoran

16

Eu também tive o mesmo problema; Eu adicionei

CELERY_IMPORTS=("mytasks")

no meu celeryconfig.pyarquivo para resolvê-lo.


6
Observe que deve ser uma lista ou uma tupla:CELERY_IMPORTS = ['my_module']
askol

Isso fez por mim
Riziero

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

inclua = ['proj.tasks'] Você precisa ir para o diretório superior e executar

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

não

celery -A celeryapp worker --loglevel=info

em seu celeryconfig.py input import = ("path.ptah.tasks",)

por favor, em outro módulo invoque a tarefa !!!!!!!!


1
O includeparâmetro precisa ser adicionado se você estiver usando importações relativas.
Resolvi

1
Votou sua resposta para esta string please in other module invoke task!!!!!!!!. Ajudou.
VolArt de

8

Usar --settings não funcionou para mim. Tive que usar o seguinte para fazer tudo funcionar:

celery --config=celeryconfig --loglevel=INFO

Aqui está o arquivo celeryconfig que tem CELERY_IMPORTS adicionado:

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

Minha configuração foi um pouco mais complicada porque estou usando o supervisor para iniciar o aipo como um daemon.


8

Para mim, esse erro foi resolvido garantindo que o aplicativo que contém as tarefas foi incluído na configuração INSTALLED_APPS do django.


Além disso, as tarefas precisavam estar acessíveis em <app> /tasks.py
np8

3

Eu tive esse problema misteriosamente surgindo quando adicionei algum tratamento de sinal ao meu aplicativo django. Ao fazer isso, converti o aplicativo para usar um AppConfig, o que significa que em vez de simplesmente ler como 'booking'em INSTALLED_APPS, ele leu 'booking.app.BookingConfig'.

Celery não entende o que isso significa, então eu adicionei, INSTALLED_APPS_WITH_APPCONFIGS = ('booking',)às minhas configurações django, e modifiquei meu celery.pyde

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

para

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

3

O que funcionou para mim foi adicionar um nome explícito ao decorador de tarefas de aipo. Eu mudei minha declaração de tarefa de @app.taskspara@app.tasks(name='module.submodule.task')

Aqui está um exemplo

# 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

Eu tive o mesmo problema ao executar tarefas do Celery Beat. O aipo não gosta de importações relativas, então, no meu celeryconfig.py, tive que definir explicitamente o nome completo do pacote:

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

Gostaria que os documentos do aipo tivessem mais exemplos com nomes de pacotes completos. Depois de ver full.path.to.add nesta resposta, descobri que não precisava das importações. Eu sabia que a solução era simples e só precisava ter um exemplo melhor do app.conf.beat_schedule.
zerocog

2

Isso, estranhamente, também pode ser devido a um pacote ausente. Execute o pip para instalar todos os pacotes necessários: pip install -r requirements.txt

autodiscover_tasks não estava pegando tarefas que usavam pacotes ausentes.


1
Eu tive uma questão semelhante. Acho que o que acontece é que uma exceção durante a importação faz com que partes da descoberta automática não sejam concluídas.
Tim Tisdall

Ahh sim, faz sentido. Obrigado
kakoma

1

Não tive nenhum problema com o Django . Mas encontrei isso quando estava usando o Flask . A solução foi definir a opção de configuração.

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

enquanto com Django, eu só tinha:

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


1

Eu também encontrei esse problema, mas não é exatamente o mesmo, então apenas para sua informação. As atualizações recentes causam essa mensagem de erro devido a esta sintaxe do decorador.

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

@task('my_server_check')

Teve que ser mudado para apenas

@task()

Não tenho ideia do porquê.


1

Se você estiver usando a configuração de aplicativos em aplicativos instalados como este:

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

Em seguida, em seu aplicativo de configuração, importe a tarefa no método pronto 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

Se você está encontrando esse tipo de erro, existem várias causas possíveis, mas a solução que encontrei foi que meu arquivo de configuração do celeryd em / etc / defaults / celeryd foi configurado para uso padrão, não para o meu projeto django específico. Assim que o converti para o formato especificado nos documentos do aipo , tudo correu bem.


0

A solução para mim adicionar esta linha a / etc / default / celeryd

CELERYD_OPTS="-A tasks"

Porque quando eu executo esses comandos:

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

Apenas o último comando estava mostrando nomes de tarefas.

Também tentei adicionar a linha CELERY_APP / etc / default / celeryd, mas também não funcionou.

CELERY_APP="tasks"

0

Tive o problema com as classes PeriodicTask no django-celery, enquanto seus nomes apareciam bem ao iniciar o trabalhador do aipo a cada execução acionada:

KeyError: u'my_app.tasks.run '

Minha tarefa era uma classe chamada 'CleanUp', não apenas um método chamado 'run'.

Quando verifiquei a tabela 'djcelery_periodictask', vi entradas desatualizadas e excluí-las corrigiu o problema.


0

Só para somar meus dois centavos para o meu caso com esse erro ...

Meu caminho está /vagrant/devops/testcom app.pye __init__.pynele.

Quando eu executo cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=info, recebo este erro.

Mas quando eu executo como se cd /vagrant/devops/test && celery worker -A app.celery --loglevel=infotudo estivesse OK.


0

Descobri que um de nossos programadores adicionou a seguinte linha a uma das importações:

os.chdir(<path_to_a_local_folder>)

Isso fez com que o trabalhador Celery mudasse seu diretório de trabalho do diretório de trabalho padrão dos projetos (onde ele poderia encontrar as tarefas) para um diretório diferente (onde ele não poderia encontrar as tarefas).

Após remover esta linha de código, todas as tarefas foram localizadas e registradas.


0

O aipo não oferece suporte a importações relativas, portanto, em meu celeryconfig.py, você precisa de importação absoluta.

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

0

Um item adicional a uma lista realmente útil.

Achei o Celery implacável em relação a erros nas tarefas (ou pelo menos não consegui rastrear as entradas de log apropriadas) e ele não os registra. Tive vários problemas ao executar o Celery como um serviço, que estavam predominantemente relacionados a permissões.

O mais recente relacionado às permissões de gravação em um arquivo de log. Não tive problemas no desenvolvimento ou na execução do aipo na linha de comando, mas o serviço relatou a tarefa como não registrada.

Eu precisava alterar as permissões da pasta de log para permitir que o serviço gravasse nela.


0

Meus 2 centavos

Eu estava obtendo isso em uma imagem docker usando alpine. As configurações do django referenciadas /dev/logpara registro no syslog. O aplicativo django e o trabalhador do aipo foram baseados na mesma imagem. O ponto de entrada da imagem do aplicativo django estava sendo syslogdiniciado no início, mas o do trabalhador de aipo não. Isso estava causando ./manage.py shellfalhas, porque não haveria nenhuma /dev/log. O trabalhador do aipo não estava falhando. Em vez disso, estava apenas ignorando silenciosamente o resto do lançamento do aplicativo, que incluía o carregamento de shared_taskentradas de aplicativos no projeto django


0

No meu caso, o erro foi porque um contêiner criou arquivos em uma pasta que foram montados no sistema de arquivos host com docker-compose.

Tive apenas que remover os arquivos criados pelo container no sistema host e pude iniciar meu projeto novamente.

sudo rm -Rf nome da pasta

(Tive que usar o sudo porque os arquivos eram propriedade do usuário root)

Versão do Docker: 18.03.1


0

Se você usar autodiscover_tasks, certifique-se de que seu functionspara ser registrado permaneça no tasks.py, e não em qualquer outro arquivo. Ou o aipo não consegue encontrar o functionsque deseja registrar.

O uso app.register_tasktambém fará o trabalho, mas parece um pouco ingênuo.

Por favor, consulte esta especificação 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

Escreva o caminho correto para as tarefas de arquivo

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

}


0

ao executar o aipo com o comando "celery -A conf worker -l info", todas as tarefas foram listadas no log como eu estava tendo. conf.celery.debug_task Eu estava recebendo o erro porque não estava fornecendo este caminho de tarefa exato. Então, por favor, verifique novamente copiando e colando a identificação exata da tarefa.


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

0

A resposta para o seu problema está na PRIMEIRA LINHA do resultado que você forneceu em sua pergunta: /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, ))) . Sem a configuração correta, o Celery não é capaz de fazer nada.

O motivo pelo qual ele não consegue encontrar o celeryconfig é mais provável que ele não esteja em seu PYTHONPATH.


0

Resolvi meu problema, minha 'tarefa' está em um pacote Python chamado 'celery_task', quando saio deste pacote e executo o comando celery worker -A celery_task.task --loglevel=info. Funciona.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.