Próbuję uruchomić przykład z dokumentacji Seleru.
Biegnę: 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())
W tym samym folderze celeryconfig.py:
CELERY_IMPORTS = ("tasks", )
CELERY_RESULT_BACKEND = "amqp"
BROKER_URL = "amqp://guest:guest@localhost:5672//"
CELERY_TASK_RESULT_EXPIRES = 300
Kiedy uruchamiam „run_task.py”:
na konsoli Pythona
eb503f77-b5fc-44e2-ac0b-91ce6ddbf153
False
błędy na serwerze 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'
Proszę wyjaśnić, na czym polega problem.
CELERY_IMPORTS = ("tasks", )
Odpowiedzi:
Możesz zobaczyć aktualną listę zarejestrowanych zadań w
celery.registry.TaskRegistry
klasie. Możliwe, że twojego celeryconfig (w bieżącym katalogu) nie ma,PYTHONPATH
więc seler nie może go znaleźć i wraca do ustawień domyślnych. Po prostu określ to wyraźnie, rozpoczynając seler.Możesz także ustawić
--loglevel=DEBUG
i prawdopodobnie powinieneś natychmiast zobaczyć problem.źródło
--loglevel=DEBUG
, w moim zadaniu wystąpił błąd składni.celery worker
np. PoDjango
tocelery --app=your_app.celery worker --loglevel=info
celery.registry.tasks
aby zobaczyć listę wszystkich moich bieżących zadań. Zawsze możesz to sprawdzić, uruchamiającdir(celery.registry)
.--loglevel=DEBUG
z mojej stronyMyślę, że musisz zrestartować serwer roboczy. Napotykam ten sam problem i rozwiązuję go, uruchamiając ponownie.
źródło
celery inspect registered
--autoreload
która uruchomi selera po każdej zmianie kodu.Miałem ten sam problem: Przyczyną
"Received unregistered task of type.."
było to, że serwis selera nie znalazł i nie zarejestrował zadań przy uruchomieniu usługi (przy okazji ich lista jest widoczna po uruchomieniu./manage.py celeryd --loglevel=info
).Zadania te należy zadeklarować w
CELERY_IMPORTS = ("tasks", )
pliku ustawień.Jeśli masz specjalny
celery_settings.py
plik, musi on zostać zadeklarowany na starcie usługi seler, tak--settings=celery_settings.py
jak napisał digivampire.źródło
Niezależnie od tego, czy używasz,
CELERY_IMPORTS
czyautodiscover_tasks
, ważne jest, aby zadania można było znaleźć, a nazwa zadań zarejestrowanych w Selerze powinna odpowiadać nazwom, które pracownicy próbują pobrać.Powiedzmy
celery worker -A project --loglevel=DEBUG
, że po uruchomieniu selera powinieneś zobaczyć nazwy zadań. Na przykład, jeśli mamdebug_task
zadanie w moimcelery.py
.Jeśli nie możesz zobaczyć swoje zadania na liście, proszę sprawdzić seler importu konfiguracji zadań prawidłowo, zarówno w
--setting
,--config
,celeryconfig
lubconfig_from_object
.Jeśli używasz rytmu selera, upewnij się, że nazwa zadania,,
task
którego używasz w,CELERYBEAT_SCHEDULE
odpowiada nazwie na liście zadań selera.źródło
@task(name='check_periodically')
to powinno pasować do tego, co umieściłeś w harmonogramieCELERY_BEAT_SCHEDULE = { 'check_periodically': { 'task': 'check_periodically', 'schedule': timedelta(seconds=1) }
Ja też miałem ten sam problem; dodałem
CELERY_IMPORTS=("mytasks")
w moim
celeryconfig.py
pliku, aby go rozwiązać.źródło
CELERY_IMPORTS = ['my_module']
app = Celery('proj', broker='amqp://', backend='amqp://', include=['proj.tasks'])
please include = ['proj.tasks'] Musisz przejść do pierwszego katalogu, a następnie wykonać to
nie
w Twoim celeryconfig.py input Import = ("path.ptah.tasks",)
proszę w innym module wywołać zadanie !!!!!!!!
źródło
include
należy dodać, jeśli używasz importu względnego. Rozwiązałem swój problem, dodając goplease in other module invoke task!!!!!!!!
. Pomogło.Użycie --settings nie działało dla mnie. Musiałem użyć następujących elementów, aby wszystko działało:
Oto plik celeryconfig, do którego dodano 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",)
Moja konfiguracja była trochę bardziej skomplikowana, ponieważ używam nadzorcy do uruchomienia selera jako demona.
źródło
Dla mnie ten błąd został rozwiązany poprzez zapewnienie, że aplikacja zawierająca zadania została uwzględniona w ustawieniach INSTALLED_APPS django.
źródło
Miałem ten problem w tajemniczych okolicznościach, kiedy dodałem obsługę sygnału do mojej aplikacji django. W ten sposób przekonwertowałem aplikację tak, aby korzystała z AppConfig, co oznacza, że zamiast po prostu czytać jako
'booking
„w”INSTALLED_APPS
, czyta'booking.app.BookingConfig'
.Seler nie rozumie, co to znaczy, więc dodałem
INSTALLED_APPS_WITH_APPCONFIGS = ('booking',)
do moich ustawień django i zmodyfikowałem plikcelery.py
fromapp.autodiscover_tasks(lambda: settings.INSTALLED_APPS)
do
app.autodiscover_tasks( lambda: settings.INSTALLED_APPS + settings.INSTALLED_APPS_WITH_APPCONFIGS )
źródło
W moim przypadku zadziałało dodanie wyraźnej nazwy do dekoratora zadań z selera. Zmieniłem deklarację zadania z
@app.tasks
na@app.tasks(name='module.submodule.task')
Oto przykład
# 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 !!!!")
źródło
Miałem ten sam problem z wykonywaniem zadań z Celery Beat. Seler nie lubi importów względnych, więc w moim
celeryconfig.py
musiałem jawnie ustawić pełną nazwę pakietu:app.conf.beat_schedule = { 'add-every-30-seconds': { 'task': 'full.path.to.add', 'schedule': 30.0, 'args': (16, 16) }, }
źródło
O dziwo, może to być również spowodowane brakującym pakietem. Uruchom pip, aby zainstalować wszystkie niezbędne pakiety:
pip install -r requirements.txt
autodiscover_tasks
nie odbierał zadań korzystających z brakujących pakietów.źródło
Nie miałem żadnego problemu z Django . Ale napotkałem to, gdy używałem Flaska . Rozwiązaniem było ustawienie opcji config.
celery worker -A app.celery --loglevel=DEBUG --config=settings
będąc z Django, właśnie miałem:
python manage.py celery worker -c 2 --loglevel=info
źródło
Napotkałem również ten problem, ale to nie to samo, więc po prostu FYI. Ostatnie aktualizacje powodują ten komunikat o błędzie z powodu tej składni dekoratora.
ERROR/MainProcess] Received unregistered task of type 'my_server_check'.
@task('my_server_check')
Musiał zostać zmieniony na sprawiedliwy
@task()
Nie mam pojęcia, dlaczego.
źródło
Jeśli używasz konfiguracji aplikacji w zainstalowanych aplikacjach, takich jak ta:
LOCAL_APPS = [ 'apps.myapp.apps.MyAppConfig']
Następnie w aplikacji konfiguracyjnej zaimportuj zadanie w gotowej metodzie w następujący sposób:
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
źródło
Spróbuj zaimportować zadanie Celery do powłoki Pythona - Celery może po cichu nie rejestrować zadań z powodu złej instrukcji importu.
Miałem
ImportError
wyjątek w moim tasks.py pliku, który był przyczyną Seler aby nie rejestrować zadania w module. Wszystkie inne zadania modułu zostały poprawnie zarejestrowane.Ten błąd nie był widoczny, dopóki nie spróbowałem zaimportować zadania Celery w powłoce Pythona. Naprawiłem błędną instrukcję importu, a następnie zadania zostały pomyślnie zarejestrowane.
źródło
Jeśli napotkasz tego rodzaju błąd, istnieje wiele możliwych przyczyn, ale rozwiązaniem, które znalazłem, było to, że mój plik konfiguracyjny celeryd w / etc / defaults / celeryd został skonfigurowany do standardowego użytku, a nie dla mojego konkretnego projektu django. Jak tylko przekonwertowałem go do formatu określonego w dokumentacji selera , wszystko było w porządku.
źródło
Rozwiązanie dla mnie dodanie tej linii do / etc / default / celeryd
CELERYD_OPTS="-A tasks"
Ponieważ kiedy uruchamiam te polecenia:
Tylko ta ostatnia komenda w ogóle pokazywała nazwy zadań.
Próbowałem również dodać linię CELERY_APP / etc / default / seleryd, ale to też nie zadziałało.
CELERY_APP="tasks"
źródło
Miałem problem z klasami PeriodicTask w django-seler, podczas gdy ich nazwy pojawiały się dobrze podczas uruchamiania pracownika selera przy każdym uruchomieniu:
KeyError: u'my_app.tasks.run '
Moim zadaniem była klasa o nazwie „CleanUp”, a nie tylko metoda o nazwie „run”.
Kiedy sprawdziłem tabelę „djcelery_periodictask”, zobaczyłem nieaktualne wpisy i usunięcie ich rozwiązało problem.
źródło
Wystarczy dodać moje dwa centy do mojej sprawy z tym błędem ...
Moja ścieżka jest
/vagrant/devops/test
z niąapp.py
i__init__.py
w niej.Po uruchomieniu
cd /vagrant/devops/ && celery worker -A test.app.celery --loglevel=info
pojawia się ten błąd.Ale kiedy go uruchamiam,
cd /vagrant/devops/test && celery worker -A app.celery --loglevel=info
wszystko jest w porządku.źródło
Odkryłem, że jeden z naszych programistów dodał następujący wiersz do jednego z importów:
Spowodowało to, że pracownik Selera zmienił swój katalog roboczy z domyślnego katalogu roboczego projektów (w którym mógł znaleźć zadania) do innego katalogu (w którym nie mógł znaleźć zadań).
Po usunięciu tej linii kodu wszystkie zadania zostały znalezione i zarejestrowane.
źródło
Seler nie obsługuje importu względnego, więc w moim celeryconfig.py potrzebujesz importu absolutnego.
CELERYBEAT_SCHEDULE = { 'add_num': { 'task': 'app.tasks.add_num.add_nums', 'schedule': timedelta(seconds=10), 'args': (1, 2) } }
źródło
Dodatkowa pozycja do naprawdę przydatnej listy.
Uważam, że Seler jest bezlitosny w odniesieniu do błędów w zadaniach (a przynajmniej nie byłem w stanie prześledzić odpowiednich wpisów w dzienniku) i nie rejestruje ich. Miałem wiele problemów z uruchomieniem Selery jako usługi, które były głównie związane z uprawnieniami.
Najnowsze związane z uprawnieniami zapisu do pliku dziennika. Nie miałem żadnych problemów z programowaniem ani uruchamianiem selera w wierszu poleceń, ale usługa zgłosiła zadanie jako niezarejestrowane.
Musiałem zmienić uprawnienia do folderu dziennika, aby umożliwić usłudze zapis do niego.
źródło
Moje 2 centy
Otrzymałem to w obrazie dockera używającym alpine. Ustawienia django, do których odwołuje się
/dev/log
logowanie do syslog. Aplikacja django i pracownik selera były oparte na tym samym obrazie. Punkt wejścia obrazu aplikacji django był uruchamianysyslogd
na starcie, ale punkt dla pracownika selera nie. To powodowało, że rzeczy takie jak./manage.py shell
niepowodzenie, ponieważ nie było/dev/log
. Pracownik selera nie zawiódł. Zamiast tego po cichu ignorował resztę uruchamiania aplikacji, która obejmowała ładowanieshared_task
wpisów z aplikacji w projekcie djangoźródło
W moim przypadku błąd polegał na tym, że jeden kontener utworzył pliki w folderze, które zostały zamontowane w systemie plików hosta za pomocą docker-compose.
Musiałem tylko usunąć pliki utworzone przez kontener w systemie hosta i mogłem ponownie uruchomić projekt.
(Musiałem użyć sudo, ponieważ pliki były własnością użytkownika root)
Wersja Dockera: 18.03.1
źródło
Jeśli używasz
autodiscover_tasks
, upewnij się, że jesteśfunctions
zarejestrowanytasks.py
, a nie inny plik. Lub seler nie może znaleźć tego,functions
który chcesz zarejestrować.Użycie
app.register_task
również spełni swoje zadanie, ale wydaje się trochę naiwne.Zapoznaj się z oficjalną specyfikacją
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. """
źródło
Wpisz poprawną ścieżkę do zadań pliku
app.conf.beat_schedule = { 'send-task': { 'task': 'appdir.tasks.testapp', 'schedule': crontab(minute='*/5'), },
}
źródło
podczas uruchamiania selera z poleceniem "seler -A conf worker -l info" wszystkie zadania były wyświetlane w dzienniku, tak jak miałem. conf.celery.debug_task Otrzymałem błąd, ponieważ nie podawałem dokładnej ścieżki zadania. Więc uprzejmie sprawdź to ponownie, kopiując i wklejając dokładny identyfikator zadania.
źródło
app = Celery(__name__, broker=app.config['CELERY_BROKER'], backend=app.config['CELERY_BACKEND'], include=['util.xxxx', 'util.yyyy'])
źródło
W odpowiedzi na Twój problem leży w pierwszym wierszu wyjścia podany w pytaniu:
/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, )))
. Bez odpowiedniej konfiguracji Seler nie jest w stanie nic zrobić.Powodem, dla którego nie może znaleźć selektora jest najprawdopodobniej nie ma go w PYTHONPATH.
źródło