SystemdDoctor
служба не работает частое состояния перезапуск

start-limit-hit: служба заблокирована после серии перезапусков

Сообщение «start request repeated too quickly» значит, что служба падала и перезапускалась слишком часто, и systemd прекратил попытки. Это защита от бесконечного цикла: она не причина сбоя, а его следствие. Разбирать нужно первое падение в серии, а не блокировку.

Что это значит

Правило задаётся двумя параметрами: StartLimitBurst= (по умолчанию 5 запусков) и StartLimitIntervalSec= (по умолчанию 10 секунд). Превысили — служба переходит в состояние failed с результатом start-limit-hit и не запускается даже вручную, пока счётчик не сброшен.

Сбросить счётчик: systemctl reset-failed имя.service. Но если исходная причина осталась, через несколько секунд всё повторится.

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

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

  1. Служба падает сразу после запуска, а Restart=always поднимает её без паузы

    Быстрое падение плюс мгновенный перезапуск дают пять попыток за считанные секунды. Настоящая причина — в первом падении.

  2. Слишком тесные пределы частоты запусков

    Для служб, которые перезапускаются по делу (например ждут появления внешнего ресурса), значения по умолчанию могут быть слишком строгими.

  3. Restart=always у службы, которая по смыслу одноразовая

    Задача типа Type=oneshot отрабатывает и завершается. С постоянным перезапуском она уходит в цикл и мгновенно упирается в предел.

Диагностика

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

Главная команда: показывает историю падений до блокировки, включая первое.

journalctl -u myapp.service --no-pager | grep -B10 "repeated too quickly" | head -40

Счётчик перезапусков и действующие пределы.

systemctl show myapp.service -p NRestarts -p StartLimitBurst -p StartLimitIntervalSec -p RestartSec

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

sudo systemctl reset-failed myapp.service && sudo systemctl status myapp.service

Решение

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

1. Служба падает сразу после запуска, а Restart=always поднимает её без паузы
Почему происходит
Быстрое падение плюс мгновенный перезапуск дают пять попыток за считанные секунды. Настоящая причина — в первом падении.
Как проверить
Найдите в журнале самую первую неудачу серии. 
journalctl -u myapp.service --no-pager | grep -B5 "repeated too quickly" | head -30
Как исправить
Сначала сбросьте состояние, затем правьте исходную причину, и только потом добавляйте паузу между попытками через RestartSec=. 
sudo systemctl reset-failed myapp.service
sudo systemctl edit myapp.service   # RestartSec=5
2. Слишком тесные пределы частоты запусков
Почему происходит
Для служб, которые перезапускаются по делу (например ждут появления внешнего ресурса), значения по умолчанию могут быть слишком строгими.
Как проверить
Посмотрите действующие пределы. 
systemctl show myapp.service -p StartLimitBurst -p StartLimitIntervalSec -p RestartSec
Как исправить
Расширьте окно: например StartLimitIntervalSec=60 и StartLimitBurst=10 вместе с RestartSec=10. Полностью отключать защиту (StartLimitIntervalSec=0) стоит только для служб, где цикл перезапуска безопасен.
3. Restart=always у службы, которая по смыслу одноразовая
Почему происходит
Задача типа Type=oneshot отрабатывает и завершается. С постоянным перезапуском она уходит в цикл и мгновенно упирается в предел.
Как проверить
Посмотрите тип и политику перезапуска. 
systemctl show myapp.service -p Type -p Restart -p RemainAfterExit
Как исправить
Уберите перезапуск у одноразовой задачи. Для регулярного выполнения используйте таймер: он вызывает службу по расписанию, а не в цикле.

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

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

× myapp.service - My application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2026-09-15 21:02:11 MSK; 3s ago

systemd[1]: myapp.service: Scheduled restart job, restart counter is at 5.
systemd[1]: myapp.service: Start request repeated too quickly.
systemd[1]: myapp.service: Failed with result 'exit-code'.
systemd[1]: Failed to start myapp.service - My application.

Частые вопросы

Почему служба не запускается даже вручную?

Пока счётчик не сброшен, systemd отказывает в запуске. Выполните systemctl reset-failed имя.service — и запуск снова станет возможен.

Можно ли просто отключить этот предел?

Можно, StartLimitIntervalSec=0, но тогда падающая служба будет перезапускаться бесконечно, заполняя журнал и расходуя ресурсы. Предел придуман не зря: лучше добавить RestartSec= и разобраться с падением.

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

  • Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
  • status=1/FAILURE в systemd Код 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
  • Failed with result 'timeout' Состояние timeout: служба не уложилась в отведённое время при запуске, остановке или перезагрузке настроек.
  • Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
  • Служба active, но не работает: обёртки и oneshot Почему состояние active не означает работающую программу: oneshot с RemainAfterExit, обёртки, потерянный главный процесс.
  • A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
  • Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
  • Apache: Invalid command — не включён модуль Apache не запускается: директива требует модуль, который не подключён. Как найти нужный модуль и включить.

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

Источники

  • systemd.unit(5)
    StartLimitIntervalSec=, StartLimitBurst= и StartLimitAction=.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.service(5)
    Restart= и RestartSec=: как складывается частота перезапусков.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на службе с Restart=always и мгновенным падением: блокировка через 5 попыток.     собственная проверка, systemd 255
    сверено 15 сентября 2026