Celery Received attività non registrata di tipo (esegui esempio)

Sto cercando di eseguire un esempio dalla documentazione di Celery.

Io 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

task.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())

Nella stessa cartella celeryconfig.py:

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

Quando eseguo "run_task.py":

sulla console Python

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

errori sul server 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'

Per favore, spiega qual è il problema.

È possibile visualizzare l'elenco corrente delle attività registrate nella celery.registry.TaskRegistryclasse. Potrebbe essere che il tuo celeryconfig (nella directory corrente) non sia in, PYTHONPATHquindi celery non può trovarlo e torna ai valori predefiniti. Basta specificarlo esplicitamente quando si inizia il sedano.

celeryd --loglevel=INFO --settings=celeryconfig

Puoi anche impostare --loglevel=DEBUGe dovresti probabilmente vedere il problema immediatamente.

Penso che sia necessario riavviare il server di lavoro. Incontro lo stesso problema e lo risolvo riavviando.

Ho avuto lo stesso problema: il motivo "Received unregistered task of type.."era che il servizio celeryd non ha trovato e registrato le attività all'avvio del servizio (btw il loro elenco è visibile quando si avvia ./manage.py celeryd --loglevel=info ).

Queste attività dovrebbero essere dichiarate nel CELERY_IMPORTS = ("tasks", )file delle impostazioni.
Se hai un celery_settings.pyfile speciale , deve essere dichiarato all'avvio del servizio --settings=celery_settings.pyceleryd come ha scritto digivampire.

Sia che usi CELERY_IMPORTSoautodiscover_tasks , il punto importante è che le attività possono essere trovate e il nome delle attività registrate in Celery dovrebbe corrispondere ai nomi che i lavoratori cercano di recuperare.

Quando avvii Celery, ad esempio celery worker -A project --loglevel=DEBUG, dovresti vedere il nome delle attività. Ad esempio, se ho debug_taskun'attività nel mio file 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 non è possibile vedere le attività nella lista, controlla le importazioni di configurazione sedano i compiti correttamente, sia in --setting, --config, celeryconfigoconfig_from_object .

Se stai usando il battito di sedano, assicurati che il nome dell'attività,, taskche usi in CELERYBEAT_SCHEDULEcorrisponda al nome nell'elenco delle attività del sedano.

Ho anche avuto lo stesso problema; Ho aggiunto

CELERY_IMPORTS=("mytasks")

nel mio celeryconfig.pyfile per risolverlo.

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

per favore includi = ['proj.tasks'] Devi andare alla directory principale, quindi eseguire questo

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

non

celery -A celeryapp worker --loglevel=info

nell'input di celeryconfig.py imports = ("path.ptah.tasks",)

per favore in un altro modulo invoca task !!!!!!!!

L'uso di --settings non ha funzionato per me. Ho dovuto usare quanto segue per far funzionare tutto:

celery --config=celeryconfig --loglevel=INFO

Ecco il file celeryconfig a cui è stato aggiunto CELERY_IMPORTS:

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

La mia configurazione è stata un po 'più complicata perché sto usando il supervisore per avviare il sedano come demone.

Per me questo errore è stato risolto assicurandomi che l'app contenente le attività fosse inclusa nell'impostazione INSTALLED_APPS di django.

Ho avuto questo problema misteriosamente quando ho aggiunto un po 'di gestione del segnale alla mia app django. In tal modo ho convertito l'app per utilizzare un AppConfig, il che significa che invece di leggere semplicemente come 'booking'in INSTALLED_APPS, legge 'booking.app.BookingConfig'.

Celery non capisce cosa significhi, quindi ho aggiunto le INSTALLED_APPS_WITH_APPCONFIGS = ('booking',)mie impostazioni di django e modificato le mie celery.pyda

app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

per

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

Quello che ha funzionato per me, è stato aggiungere un nome esplicito al compito di decoratore del sedano. Ho cambiato la mia dichiarazione di attività da @app.tasksa@app.tasks(name='module.submodule.task')

Ecco un esempio

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

Ho avuto lo stesso problema durante l'esecuzione di attività da Celery Beat. A Celery non piacciono le importazioni relative, quindi nel mio celeryconfig.py, ho dovuto impostare esplicitamente il nome completo del pacchetto:

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

Questo, stranamente, può anche essere dovuto a un pacco mancante. Esegui pip per installare tutti i pacchetti necessari: pip install -r requirements.txt

autodiscover_tasks non stava raccogliendo attività che utilizzavano pacchetti mancanti.

Non ho avuto problemi con Django . Ma l'ho riscontrato quando stavo usando Flask . La soluzione è stata l'impostazione dell'opzione di configurazione.

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

mentre con Django, ho appena avuto:

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

Ho riscontrato anche questo problema, ma non è proprio lo stesso, quindi solo FYI. Gli aggiornamenti recenti causano questo messaggio di errore a causa di questa sintassi del decoratore.

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

@task('my_server_check')

Doveva essere cambiato in appena

@task()

Non ho idea del perché.

Se stai utilizzando la configurazione delle app in app installate come questa:

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

Quindi nella tua app di configurazione, importa l'attività nel metodo pronto in questo modo:

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

Se stai riscontrando questo tipo di errore, ci sono una serie di possibili cause, ma la soluzione che ho trovato è stata che il mio file di configurazione celeryd in / etc / defaults / celeryd era configurato per l'uso standard, non per il mio progetto django specifico. Non appena l'ho convertito nel formato specificato nei documenti sul sedano , è andato tutto bene.

La soluzione per me di aggiungere questa riga a / etc / default / celeryd

CELERYD_OPTS="-A tasks"

Perché quando eseguo questi comandi:

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

Solo l'ultimo comando mostrava i nomi delle attività.

Ho anche provato ad aggiungere la riga CELERY_APP / etc / default / celeryd ma neanche questo ha funzionato.

CELERY_APP="tasks"

Ho avuto il problema con le classi PeriodicTask in django-sedano, mentre i loro nomi si sono presentati bene quando si avviava il lavoratore del sedano ogni esecuzione attivata:

KeyError: u'my_app.tasks.run '

Il mio compito era una classe chiamata "CleanUp", non solo un metodo chiamato "run".

Quando ho controllato la tabella 'djcelery_periodictask' ho visto voci obsolete e l'eliminazione ha risolto il problema.

Solo per aggiungere i miei due centesimi per il mio caso con questo errore ...

Il mio percorso è /vagrant/devops/testcon app.pye__init__.py dentro.

Quando corro cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=inforicevo questo errore.

Ma quando lo eseguo come se fosse cd /vagrant/devops/test && celery worker -A app.celery --loglevel=infotutto OK.

Ho scoperto che uno dei nostri programmatori ha aggiunto la seguente riga a una delle importazioni:

os.chdir(<path_to_a_local_folder>)

Ciò ha fatto sì che il lavoratore Celery cambi la sua directory di lavoro dalla directory di lavoro predefinita del progetto (dove poteva trovare le attività) a una directory diversa (dove non poteva trovare le attività).

Dopo aver rimosso questa riga di codice, tutte le attività sono state trovate e registrate.

Celery non supporta le importazioni relative, quindi nel mio celeryconfig.py è necessaria l'importazione assoluta.

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

Un elemento aggiuntivo a una lista davvero utile.

Ho trovato Celery spietato in relazione agli errori nelle attività (o almeno non sono stato in grado di rintracciare le voci di registro appropriate) e non le registra. Ho avuto una serie di problemi con l'esecuzione di Celery come servizio, che sono stati principalmente correlati alle autorizzazioni.

L'ultima relativa alle autorizzazioni di scrittura in un file di registro. Non ho avuto problemi nello sviluppo o nell'esecuzione di sedano dalla riga di comando, ma il servizio ha segnalato l'attività come non registrata.

Avevo bisogno di modificare le autorizzazioni della cartella di registro per consentire al servizio di scrivere su di essa.

I miei 2 centesimi

Lo stavo ottenendo in un'immagine docker usando alpine. Le impostazioni di django a cui si fa riferimento /dev/logper la registrazione a syslog. L'app django e il lavoratore sedano erano entrambi basati sulla stessa immagine. Il punto di ingresso dell'immagine dell'app Django si stava avviando syslogdall'avvio, ma quello per il lavoratore del sedano no. Questo stava facendo ./manage.py shellfallire cose come perché non ce ne sarebbero state /dev/log. Il lavoratore del sedano non stava fallendo. Invece, ignorava silenziosamente il resto del lancio dell'app, che includeva il caricamento di shared_taskvoci dalle applicazioni nel progetto django

Nel mio caso l'errore era dovuto al fatto che un contenitore ha creato file in una cartella che sono stati montati sul file system host con docker-compose.

Dovevo solo rimuovere i file creati dal contenitore sul sistema host e sono stato in grado di avviare nuovamente il mio progetto.

sudo rm -Rf nomecartella

(Ho dovuto usare sudo perché i file erano di proprietà dell'utente root)

Versione Docker: 18.03.1

Se usi autodiscover_tasks, assicurati che la tua functionsregistrazione rimanga nel tasks.pyfile, non in qualsiasi altro file. O il sedano non riesce a trovare ilfunctions che vuoi registrare.

Uso app.register_task farà il lavoro, ma sembra un po 'ingenuo.

Fare riferimento a questa specifica ufficiale di 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.
    """

Scrivi il percorso corretto per le attività sui file

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

}

quando si esegue il sedano con il comando "celery -A conf worker -l info" tutte le attività sono state elencate nel registro come stavo facendo io. conf.celery.debug_task stavo ottenendo l'errore perché non stavo dando questo esatto percorso dell'attività. Quindi ricontrollalo gentilmente copiando e incollando l'ID esatto dell'attività.

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

La risposta al tuo problema sta nella PRIMA LINEA dell'output che hai fornito nella tua domanda: /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, ))) . Senza la giusta configurazione Celery non è in grado di fare nulla.

Il motivo per cui non riesce a trovare la configurazione di sedano è molto probabile che non sia nel tuo PYTHONPATH.

Ho risolto il mio problema, la mia "attività" si trova in un pacchetto Python denominato "celery_task" ， quando esco da questo pacchetto ed eseguo il comando celery worker -A celery_task.task --loglevel=info. Funziona.