SystemdDoctor
мешает работе надзор процессы

supervisord под systemd: два надзорщика за одними процессами

Два надзорщика за одними процессами дают неопределённое поведение: остановка через один из них означает перезапуск другим, а состояние службы в systemd не отражает реальность. Схема встречается при переносе старых установок и почти всегда лишняя.

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

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

  1. systemd видит только надзорщика, а не приложения

    Для systemd работает один процесс. Падение отдельного приложения внутри для него невидимо, и служба остаётся в рабочем состоянии при нерабочем приложении.

  2. Остановка не срабатывает: процессы поднимаются заново

    Остановленное одним надзорщиком приложение поднимает второй. Снаружи это выглядит как невозможность остановить службу.

  3. Журналы приложений не попадают в журнал системы

    Надзорщик пишет вывод приложений в свои файлы. Разбор идёт мимо журнала, и привязки к unit нет.

Диагностика

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

Состояние приложений внутри надзорщика.

sudo supervisorctl status

Дерево процессов службы: видно всё, что запущено внутри.

systemd-cgls -u supervisor.service

Как systemd обращается со своим надзорщиком.

systemctl show supervisor -p Restart -p KillMode

Решение

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

1. systemd видит только надзорщика, а не приложения
Почему происходит
Для systemd работает один процесс. Падение отдельного приложения внутри для него невидимо, и служба остаётся в рабочем состоянии при нерабочем приложении.
Как проверить
Сравните состояние службы и приложений внутри. 
systemctl status supervisor --no-pager | head -6
sudo supervisorctl status 2>/dev/null
Как исправить
Перенесите приложения в отдельные unit-файлы systemd. Тогда состояние, журнал и перезапуск каждого будут видны штатными средствами.
2. Остановка не срабатывает: процессы поднимаются заново
Почему происходит
Остановленное одним надзорщиком приложение поднимает второй. Снаружи это выглядит как невозможность остановить службу.
Как проверить
Посмотрите, кто родитель процессов приложения. 
ps -eo pid,ppid,cmd | grep -v grep | grep myapp | head
systemd-cgls -u supervisor.service 2>/dev/null | head
Как исправить
Оставьте одного надзорщика. Если надзорщик приложений нужен, systemd не должен перезапускать его процессы, и наоборот.
3. Журналы приложений не попадают в журнал системы
Почему происходит
Надзорщик пишет вывод приложений в свои файлы. Разбор идёт мимо журнала, и привязки к unit нет.
Как проверить
Посмотрите, куда идут журналы приложений. 
sudo grep -hE "^logfile|stdout_logfile" /etc/supervisor/supervisord.conf /etc/supervisor/conf.d/* 2>/dev/null | head
Как исправить
При переносе в systemd вывод пойдёт в журнал с привязкой к unit. Это единственный способ искать по всем службам сразу.

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

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

$ systemctl status supervisor --no-pager | head -3
● supervisor.service - Supervisor process control system
     Active: active (running) since Mon 2026-09-15 09:14:02 MSK; 7h ago

$ sudo supervisorctl status
myapp     FATAL     Exited too quickly (process log may have details)

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

Источники

  • Документация Supervisor документация программы
    сверено 15 сентября 2026
  • systemd.service(5)
    Отслеживание процессов службы и режимы остановки.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено надзорщиком под systemd с падающим приложением внутри.     собственная проверка, systemd 255
    сверено 15 сентября 2026