SystemdDoctor
мешает работе очереди python

Celery: обработчик работает, но задачи не берутся

Обработчик очереди при потере связи с брокером продолжает работать как служба и повторяет попытки. Состояние active тут ничего не говорит: проверять надо, потребляет ли он задачи.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Обработчик слушает не ту очередь

    Имя очереди задаётся ключом запуска. При расхождении с тем, куда пишет приложение, задачи копятся, а обработчик простаивает.

  2. Брокер недоступен

    Обработчик повторяет подключение и пишет об этом в журнал, но службу не роняет.

  3. Предел одновременных задач равен нулю или процессы заняты

    Если все обработчики заняты долгими задачами, новые не берутся. Внешне это похоже на простой.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Что делает обработчик: подключается, ждёт, берёт задачи.

journalctl -u myapp-worker.service -n 40 --no-pager | tail -20

Очереди, число сообщений и подписчиков.

sudo rabbitmqctl list_queues name messages consumers 2>/dev/null | head

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Обработчик слушает не ту очередь
Почему происходит
Имя очереди задаётся ключом запуска. При расхождении с тем, куда пишет приложение, задачи копятся, а обработчик простаивает.
Как проверить
Посмотрите ключи запуска и очереди у брокера.
systemctl cat myapp-worker.service | grep -i ExecStart
sudo rabbitmqctl list_queues name messages 2>/dev/null | head
Как исправить
Приведите имена очередей к одному значению в приложении и в ключах обработчика.
2. Брокер недоступен
Почему происходит
Обработчик повторяет подключение и пишет об этом в журнал, но службу не роняет.
Как проверить
Посмотрите журнал обработчика.
journalctl -u myapp-worker.service -n 30 --no-pager | grep -iE "connect|broker"
Как исправить
Восстановите доступность брокера и добавьте зависимость в unit-файл, чтобы порядок запуска был верным.
3. Предел одновременных задач равен нулю или процессы заняты
Почему происходит
Если все обработчики заняты долгими задачами, новые не берутся. Внешне это похоже на простой.
Как проверить
Посмотрите активные задачи.
systemctl status myapp-worker.service --no-pager | grep -i tasks
Как исправить
Ограничьте время выполнения задач и добавьте обработчиков. Долгие задачи стоит выносить в отдельную очередь.

Пример вывода

Обработчик подключён к другой очереди. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

celery[1200]: [INFO/MainProcess] Connected to amqp://app@127.0.0.1:5672//
celery[1200]: [INFO/MainProcess] celery@web1 ready.

$ sudo rabbitmqctl list_queues name messages consumers
default 14028 0
celery      0 4

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация Celery: обработчики документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено расхождением имён очередей между приложением и обработчиком.
    собственная проверка, systemd 255
    сверено 15 сентября 2026