systemd: Start request repeated too quickly — служба не запускается

#Что означает ошибка

Failed with result 'start-limit-hit' и Start request repeated too quickly означают, что служба падала и перезапускалась слишком часто, и systemd временно прекратил попытки (по умолчанию более 5 запусков за 10 секунд). Само ограничение — симптом, а причина в падении сервиса.

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

Увеличение лимита лишь прячет проблему.

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

#Причины и решения

#Пошаговое решение

1. Прочитайте журнал службыВ терминале сервера выполните systemctl status имя.service --no-pager и sudo journalctl -u имя.service -b -n 100 --no-pager. Сообщение Start request repeated too quickly означает, что systemd остановил повторные попытки после нескольких неудачных запусков; первопричина находится в предшествующих строках.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Последние строки журнала.

   sudo journalctl -u имя_службы -n 50 --no-pager

2. Запустите ExecStart вручнуюПросмотрите фактическую команду запуска systemctl cat имя.service, пользовательскую учётную запись и окружение. Не запускайте потенциально разрушающий ExecStart вручную под root: сначала проверьте его смысл, пути, аргументы и безопасность; если допустимо, тестируйте в той же учётной записи и на стенде.
3. Исправьте причинуИсправьте подтверждённую причину: недоступный порт, отсутствующий файл конфигурации, неверный путь, пользователь или отказ подключения к базе. Перед изменением сохраните конфигурацию и запустите штатный тест синтаксиса программы; не скрывайте ошибку увеличением допустимого числа перезапусков.
4. Сбросьте счётчикПосле исправления выполните sudo systemctl reset-failed имя.service, затем sudo systemctl start имя.service и проверьте статус. reset-failed только сбрасывает счётчик ошибок, а не чинит службу; если причина осталась, сообщение вскоре вернётся.
5. Настройте RestartSec и лимитыПараметры Restart=, RestartSec= и StartLimitBurst изменяйте только при понимании нормального режима работы программы и после устранения сбоя. Для постоянной службы полезна разумная задержка, но бесконечные рестарты без диагностики создают дополнительную нагрузку. Сравните журнал после запуска.

#Причина падения

Посмотрите журнал: journalctl -u имя.service -n 80 --no-pager — найдите сообщения перед началом цикла. Запустите команду из ExecStart вручную от нужного пользователя и посмотрите ошибку (неверный конфиг, занятый порт, нет прав, не найден файл). Проверьте код выхода в systemctl status. Если сервис форкается, но юнит ждёт Type=simple, измените Type=forking и укажите PIDFile.

#Сброс и перезапуск

После исправления сбросьте состояние: sudo systemctl reset-failed имя.service, затем sudo systemctl start имя.service. Если ошибка в самом юните, проверьте синтаксис systemd-analyze verify и выполните sudo systemctl daemon-reload. Убедитесь, что порт свободен: ss -ltnp | grep :80.

#Настройка перезапуска

Для нестабильных служб задайте задержку: в systemctl edit имя.service добавьте [Service] → Restart=on-failure → RestartSec=5. Лимит старта настраивается в секции [Unit]: StartLimitIntervalSec=60 и StartLimitBurst=10. Не отключайте лимит (StartLimitIntervalSec=0) без причины: службы-«петли» будут нагружать систему. Следите за зависимостями (After=network-online.target, Requires=), иначе сервис падает при рано запущенной сети.