Планировщик задач запускает задания дважды
Планировщик периодических заданий должен быть один. Два экземпляра дают двойное выполнение: письма уходят дважды, счётчики растут вдвое. Частая причина — планировщик, запущенный и службой, и вручную, либо один файл расписания на два узла.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Планировщик запущен дважды
Служба и ручной запуск работают одновременно. Каждый ставит задания по своему расписанию.
-
Файл расписания в общем каталоге
При хранении расписания на общем разделе два узла пишут в один файл и мешают друг другу.
-
Планировщик работает на нескольких узлах
В отказоустойчивой схеме планировщик поднимают на всех узлах. Задания ставятся столько раз, сколько узлов.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Сколько планировщиков работает на этой машине.
pgrep -a -f "celery.*beat"Как запускается планировщик и где его расписание.
systemctl cat celery-beat 2>/dev/nullКакие задания и когда ставились.
journalctl -u celery-beat -n 30 --no-pagerРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Служба и ручной запуск работают одновременно. Каждый ставит задания по своему расписанию.
- Как проверить
-
Посмотрите процессы планировщика.
pgrep -a -f "celery.*beat" | head systemctl is-active celery-beat 2>/dev/null
- Как исправить
- Оставьте один планировщик и запускайте его только службой. Ручной запуск на боевой машине легко забыть остановить.
- Почему происходит
- При хранении расписания на общем разделе два узла пишут в один файл и мешают друг другу.
- Как проверить
-
Посмотрите путь к файлу расписания и тип файловой системы.
systemctl cat celery-beat 2>/dev/null | grep -iE "schedule|ExecStart" findmnt -T /var/lib/celery -o TARGET,FSTYPE 2>/dev/null
- Как исправить
-
Держите файл расписания на локальном разделе узла и объявляйте каталог через
StateDirectory=. Разделять его между узлами нельзя.
- Почему происходит
- В отказоустойчивой схеме планировщик поднимают на всех узлах. Задания ставятся столько раз, сколько узлов.
- Как проверить
-
Посмотрите, где включена служба планировщика.
systemctl is-enabled celery-beat 2>/dev/null
- Как исправить
- Планировщик должен работать на одном узле. Для отказоустойчивости используйте внешнюю блокировку или переносите его вслед за общим адресом.
Пример вывода
Планировщик запущен и службой, и вручную. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
$ pgrep -a -f "celery.*beat"
6100 /opt/app/venv/bin/celery -A app beat --schedule /var/lib/celery/beat-schedule
6240 /opt/app/venv/bin/celery -A app beat
celery-beat[6100]: Scheduler: Sending due task send-digest (app.tasks.send_digest)
celery-beat[6240]: Scheduler: Sending due task send-digest (app.tasks.send_digest)Связанные ошибки
- Celery: обработчик работает, но задачи не берутся Служба обработчика активна, очередь растёт: не та очередь, недоступный брокер, префикс имён.
- Два таймера на одну службу: срабатывания накладываются Одна служба вызывается несколькими таймерами: запуски накладываются, часть срабатываний теряется.
- keepalived: оба узла считают себя главным Общий адрес поднят на двух узлах сразу: объявления VRRP не доходят. Разбор блокировок и настроек.
- Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
- Задача cron не выполняется Задача в crontab не запускается: короткий PATH, права на файл задачи, точка в имени файла, отсутствие перевода строки.
- Пропущенное срабатывание таймера: Persistent и выключенная машина Таймер не выполнил задачу, потому что в момент срабатывания машина была выключена или служба была недоступна. Как работает Persistent=true.
- Таймер активен, но не срабатывает Таймер systemd в состоянии active, но служба не запускается. Разбор: нет условия срабатывания, таймер не включён, ошибка в OnCalendar.
- Узлы очередей не соединяются: не совпадает файл общего секрета Узлы не видят друг друга, а команды управления отказывают: файл общего секрета различается или недоступен.
Источники
- Документация Celery: периодические задания
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено двумя одновременно работающими планировщиками.