Как снять блокировку systemd после частых падений сервиса

Блокировка systemd после серии неудачных запусков снимается командой systemctl reset-failed. Для конкретного сервиса выполните sudo systemctl reset-failed example.service, а затем снова запустите юнит. Однако сначала нужно устранить причину падения: сброс не исправляет конфигурацию приложения и не предотвращает повторное достижение лимита.

Как понять, что сработал лимит запусков

Начните с проверки состояния сервиса:

systemctl status example.service

Вместо example.service укажите фактическое имя юнита. При достижении ограничения частоты запусков в сообщениях systemd может появляться строка Start request repeated too quickly. Само состояние failed не означает, что сработал именно лимит: процесс мог завершиться из-за ошибки конфигурации, отсутствующего файла, неправильных прав, недоступной зависимости или ненулевого кода возврата.

Посмотрите журнал сервиса:

journalctl -b -u example.service

Если нужны сообщения не только текущей загрузки системы, уберите параметр -b:

journalctl -u example.service

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

Как снять блокировку

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

sudo systemctl reset-failed example.service

Затем снова запустите сервис:

sudo systemctl start example.service

Проверьте результат:

systemctl status example.service
journalctl -b -u example.service

systemctl reset-failed не ремонтирует сервис и не изменяет unit-файлы. Команда сбрасывает состояние ошибки и связанные с ограничением запуска счётчики. Если процесс продолжает аварийно завершаться, systemd снова может прекратить попытки запуска после достижения установленного лимита.

Проверить Restart и ограничение частоты запусков

Чтобы увидеть основной unit-файл и подключённые drop-in-фрагменты, используйте:

systemctl cat example.service

systemctl cat полезен для поиска того, откуда взялась конкретная директива, но команда не вычисляет итоговое значение всех свойств менеджера systemd. Поэтому после просмотра файлов отдельно проверьте фактически загруженные значения существенных параметров:

systemctl show example.service \
  -p Restart \
  -p RestartUSec \
  -p StartLimitIntervalUSec \
  -p StartLimitBurst

Так можно сопоставить содержимое основного unit-файла и drop-in-файлов с параметрами, которые менеджер systemd применил к загруженному юниту.

Для автоматического перезапуска в секции [Service] обычно используют директивы семейства Restart=. Например:

[Service]
Restart=on-failure
RestartSec=5s

Restart=on-failure предписывает повторный запуск после определённых неуспешных завершений сервиса. RestartSec= задаёт паузу перед следующей попыткой. Точное поведение зависит от типа завершения процесса и версии systemd, поэтому для установленной системы его следует сверять с локальной страницей руководства:

man systemd.service

Ограничение частоты запусков в современных версиях systemd задаётся параметрами юнита:

[Unit]
StartLimitIntervalSec=60s
StartLimitBurst=5

Значения 60s и 5 здесь служат только примером. Подбирать лимит нужно с учётом поведения приложения, времени восстановления и допустимой частоты повторных запусков.

Механизмы выполняют разные задачи: Restart= определяет необходимость повторного запуска процесса, а StartLimitIntervalSec= вместе с StartLimitBurst= ограничивает частоту запусков. Слишком частые рестарты способны быстро исчерпать разрешённое число попыток.

Как изменить настройки через drop-in

Не редактируйте поставляемый пакетом unit-файл без необходимости. Для локального переопределения откройте drop-in:

sudo systemctl edit example.service

Например, можно увеличить задержку перед повторным запуском:

[Service]
Restart=on-failure
RestartSec=10s

Или изменить параметры ограничения запусков:

[Unit]
StartLimitIntervalSec=120s
StartLimitBurst=5

После сохранения перечитайте unit-файлы:

sudo systemctl daemon-reload

Проверьте исходный unit и подключённые переопределения:

systemctl cat example.service

Затем проверьте загруженные значения:

systemctl show example.service \
  -p Restart \
  -p RestartUSec \
  -p StartLimitIntervalUSec \
  -p StartLimitBurst

После изменения конфигурации сбросьте уже накопленное состояние ограничения и запустите сервис:

sudo systemctl reset-failed example.service
sudo systemctl start example.service

Завершите проверку просмотром состояния и журнала:

systemctl status example.service
journalctl -b -u example.service

Когда можно отключить ограничение запусков

В версиях systemd, поддерживающих StartLimitIntervalSec=, нулевой интервал используется для отключения ограничения частоты запусков:

[Unit]
StartLimitIntervalSec=0

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

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

Почему reset-failed не решает проблему

Процесс сразу завершается снова

После reset-failed счётчик может быть успешно сброшен, но приложение при следующем старте снова завершится с той же ошибкой. Проверьте журнал:

journalctl -b -u example.service

Если приложение ведёт собственные журналы вне journald, проверьте также их. Не увеличивайте лимиты только для того, чтобы скрыть постоянно повторяющуюся ошибку процесса.

Сбрасывается не тот юнит

Проверьте точное имя:

systemctl status example.service

На одной системе могут существовать похожие сервисы, шаблонные юниты и отдельные экземпляры шаблона. Сбрасывать состояние нужно для того юнита, который фактически достигает ограничения.

Настройка приходит из drop-in

Просмотр только файла из каталога поставщика может скрыть локальное переопределение. Используйте:

systemctl cat example.service

Команда покажет исходный unit-файл и подключённые drop-in-фрагменты. После этого через systemctl show проверьте фактически загруженные значения интересующих свойств.

Сервис снова активируется другим механизмом

Юнит может запускаться не только вручную. Причиной новой активации способны быть зависимости и другие механизмы systemd. Если запуск кажется неожиданным, изучите сообщения менеджера непосредственно перед стартом и связанные с юнитом зависимости, а не только последнюю ошибку самого процесса.

Учитывайте версию systemd

Перед изменением лимитов определите установленную версию:

systemd --version

Названия и доступность отдельных директив менялись между выпусками systemd. В частности, на старых системах вместо современного имени StartLimitIntervalSec= можно встретить прежнее имя StartLimitInterval=. Нельзя без проверки переносить конфигурацию современной системы на старый сервер: поддерживаемые имена параметров и допустимое место их задания следует определять по документации именно установленной версии.

Проверьте локальные руководства:

man systemd.unit
man systemd.service
man systemctl

Дополнительно можно выяснить, какие свойства текущий менеджер предоставляет для конкретного загруженного юнита:

systemctl show example.service

Если свойства или директивы из примеров отсутствуют в документации вашей версии, не добавляйте их вслепую. Используйте название и синтаксис, описанные в локальном руководстве для установленного systemd.

Рабочая последовательность диагностики

Проверьте состояние командой systemctl status example.service.
Просмотрите журнал через journalctl -b -u example.service.
Найдите исходную причину завершения приложения, а не только сообщение об исчерпании попыток запуска.
Определите версию командой systemd --version.
Посмотрите основной unit и drop-in-файлы через systemctl cat example.service.
Проверьте существенные фактически загруженные свойства через systemctl show.
При необходимости исправьте приложение, права, зависимости, пути к файлам или его конфигурацию.
Если требуется изменение политики рестартов, создайте локальный drop-in через systemctl edit.
После изменения unit-конфигурации выполните systemctl daemon-reload.
Сбросьте состояние командой systemctl reset-failed example.service.
Запустите сервис и повторно проверьте состояние и журнал.

Как проверить результат

Успешное выполнение systemctl start само по себе недостаточно: процесс может завершиться через несколько секунд и снова войти в цикл рестартов. Проверьте состояние и последние сообщения:

systemctl status example.service
journalctl -b -u example.service

Если вы меняли политику запуска, дополнительно убедитесь, что systemd действительно загрузил нужные параметры:

systemctl show example.service \
  -p Restart \
  -p RestartUSec \
  -p StartLimitIntervalUSec \
  -p StartLimitBurst

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

Итоговый чек-лист

Убедиться по состоянию и журналу, что действительно достигнут лимит запусков.
Найти первичную причину падения приложения.
Проверить установленную версию systemd.
Просмотреть основной unit и drop-in-файлы через systemctl cat.
Проверить применённые свойства через systemctl show.
Сверить версионно-зависимые директивы с локальными man systemd.unit и man systemd.service.
Не использовать reset-failed вместо исправления причины сбоя.
После изменения unit-файлов выполнить systemctl daemon-reload.
После исправления выполнить systemctl reset-failed example.service и запустить сервис.
Повторно проверить состояние, журнал и фактически загруженные параметры.
Не отключать ограничитель частоты запусков без обоснованной эксплуатационной причины.