Start request repeated too quickly: systemd перестал запускать службу

Как выглядит ошибка

На команду sudo systemctl start myapp systemctl отвечает:

Job for myapp.service failed because start of the service was attempted too often.
See "systemctl status myapp.service" and "journalctl -xeu myapp.service" for details.
To force a start use "systemctl reset-failed myapp.service"
followed by "systemctl start myapp.service" again.

А в журнале службы есть строки:

myapp.service: Start request repeated too quickly.
myapp.service: Failed with result 'start-limit-hit'.

В примерах служба называется myapp — подставьте имя своей: nginx, mysql, php8.3-fpm и так далее.

Что случилось

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

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

Шаг 1. Найдите первую ошибку в журнале

Команды на этой странице вводятся на сервере: подключитесь к нему по SSH (как подключиться) и набирайте их в том же окне.

sudo journalctl -u myapp -n 100 --no-pager

Если система спросит пароль, введите пароль своего пользователя на сервере. Символы при вводе не видны — так и должно быть: наберите пароль и нажмите Enter. Строки Start request repeated too quickly — в самом конце. Выше вы увидите несколько одинаковых попыток запуска. Нужна ошибка, которую программа пишет в каждой из них, — она и есть причина. Что она может значить, разобрано на странице Job for … failed.

Шаг 2. Исправьте причину

Исправьте то, о чём пишет программа: настройки, права на файлы, занятый порт. Если вы меняли файл самой службы, сообщите об этом systemd:

sudo systemctl daemon-reload

Шаг 3. Сбросьте счётчик и запустите службу

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

sudo systemctl reset-failed myapp

И запустите службу:

sudo systemctl start myapp

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

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

sudo systemctl status myapp

В строке Active: должно быть active (running). Подождите полминуты и выполните команду ещё раз: если служба падает не сразу, а через несколько секунд после старта, это будет видно. Чтобы вернуться к вводу команд после systemctl status, нажмите клавишу Q.

Можно ли просто увеличить предел

Можно — настройками StartLimitIntervalSec= и StartLimitBurst= в разделе [Unit] файла службы. Но это не лечит причину: служба будет падать и дальше, просто дольше. Меняйте предел, только если служба действительно должна перезапускаться много раз подряд, и вы знаете почему.

Тексты сообщений сверены с исходным кодом systemd 255 — эта версия стоит в Ubuntu 24.04. В других версиях systemd слова могут немного отличаться.

Источники

• Исходный код systemd 255: bus-wait-for-jobs.c — тексты Job for … failed и пояснения к ним.
• Исходный код systemd 255: unit.c — тексты Start request repeated too quickly и Failed with result.
• Исходный код systemd 255: service.c — названия результатов: exit-code, start-limit-hit, oom-kill.
• Справка systemd-system.conf(5) в Ubuntu 24.04 — по умолчанию 5 запусков за 10 секунд.
• Справка systemd.unit(5) в Ubuntu 24.04 — где лежат файлы служб, StartLimitBurst.
• Справка systemctl(1) в Ubuntu 24.04 — команды reset-failed, daemon-reload, unmask.

Сверено 10 октября 2026 года.

Что почитать дальше

• Job for … failed: служба не запускается.
• Все ошибки systemd и диска.