мешает работе мониторинг состояния частое

Служба active, но не работает: обёртки и oneshot

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

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

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

Одноразовая задача с сохранением состояния

При Type=oneshot и RemainAfterExit=yes состояние становится active (exited) и остаётся таким. Это задумано: так отмечают выполненное действие.
Unit — обёртка над другими unit

Обёртки вроде postgresql.service ничего не запускают сами. Их состояние не связано с работой настоящих служб.
systemd потерял главный процесс

При Type=forking без PIDFile= угадывание может выбрать не тот процесс. Тогда состояние active не соответствует действительности: настоящий процесс мог умереть.

Диагностика

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

Четыре значения, которые объясняют расхождение состояния и реальности.

systemctl show myapp.service -p Type -p MainPID -p SubState -p RemainAfterExit

Список процессов контрольной группы: если он пуст, программы нет.

systemctl status myapp.service --no-pager | tail -8

Для мониторинга это надёжнее проверки на active.

systemctl is-failed myapp.service

Решение

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

1. Одноразовая задача с сохранением состояния

Почему происходит: При Type=oneshot и RemainAfterExit=yes состояние становится active (exited) и остаётся таким. Это задумано: так отмечают выполненное действие.

Как проверить

Посмотрите подстояние и параметры.

systemctl show myapp.service -p Type -p RemainAfterExit -p SubState

Как исправить: Проверяйте не состояние, а результат: подстояние exited и код последнего запуска. Для мониторинга полезнее systemctl is-failed и проверка самой службы по её порту или ответу.

2. Unit — обёртка над другими unit

Почему происходит: Обёртки вроде postgresql.service ничего не запускают сами. Их состояние не связано с работой настоящих служб.

Как проверить

Посмотрите, есть ли у unit процессы.

systemctl show myapp.service -p MainPID -p ExecMainPID
systemctl status myapp.service --no-pager | tail -5

Как исправить: Найдите настоящий unit и проверяйте его. Нулевой главный процесс у активной службы — верный признак обёртки.

3. systemd потерял главный процесс

Почему происходит: При Type=forking без PIDFile= угадывание может выбрать не тот процесс. Тогда состояние active не соответствует действительности: настоящий процесс мог умереть.

Как проверить

Сравните главный процесс по данным systemd и фактические процессы.

systemctl show myapp.service -p MainPID
ps -ef | grep -v grep | grep myapp

Как исправить: Задайте PIDFile= или, лучше, откажитесь от демонизации и используйте Type=simple.

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

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

● migrate.service - Применение миграций
     Loaded: loaded (/etc/systemd/system/migrate.service; enabled)
     Active: active (exited) since Mon 2026-09-15 08:00:02 MSK; 6h ago
    Process: 1200 ExecStart=/usr/local/bin/migrate (code=exited, status=0/SUCCESS)
   Main PID: 1200 (code=exited, status=0/SUCCESS)

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

status=0/SUCCESS, но служба считается упавшей Программа завершилась успешно, а systemctl показывает inactive или failed. Разбор: Type=simple против forking, RemainAfterExit, демонизация.
postgresql.service активен, а кластер не работает Обёртка postgresql.service — пустой oneshot. Почему её состояние ничего не говорит о кластере и что смотреть.
Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Failed with result 'timeout' Состояние timeout: служба не уложилась в отведённое время при запуске, остановке или перезагрузке настроек.
start-limit-hit: служба заблокирована после серии перезапусков Состояние start-limit-hit и сообщение start request repeated too quickly: systemd перестал перезапускать службу. Как разблокировать и найти исходную причину.
Система загрузилась в состоянии degraded systemctl is-system-running возвращает degraded: часть служб не запустилась. Как найти их и что делать.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.

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

postgresql.service 8

Источники

systemctl(1)
Состояния и подстояния unit. официальная документация, systemd 255
сверено 15 сентября 2026
systemd.service(5)
RemainAfterExit= и Type=forking. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на oneshot с RemainAfterExit и на forking без PIDFile. собственная проверка, systemd 255
сверено 15 сентября 2026