Запрос на запуск службы повторен слишком быстро, отказ в запуске

23

У меня есть сервис systemd, который отображает следующую ошибку service start request repeated too quickly, refusing to start

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

Более того, что too quicklyименно означает ли это ограничение количества перезапусков за определенный период времени?

linux systemd

— Викас Тивари
источник

26

Предельное значение по умолчанию - 5 перезапусков за 10 секунд. Если служба превысит этот порог из-за параметра Restart=конфигурации в определении службы, она не будет пытаться перезапустить дальше.

Скорости настраиваются с StartLimitIntervalSec=и StartLimitBurst=опций , а также Restart=управления опционных когда Systemd пытается перезапустить службу.

Больше информации в man systemd.unitа man systemd.service.

Затем используйте systemctl daemon-reloadдля перезагрузки конфигурации устройства.

— Свен
источник

3

Спасибо @ Свен. Где эти конфигурации определены?

— Викас Тивари

В служебном файле. Эти StartLimit...параметры могут быть там и просто использовать по умолчанию (5 перезагружается в 10 сек).

— Свен

Значение по умолчанию записано в каком-то другом файле конфигурации?

— Викас Тивари

3

Значения по умолчанию можно настроить, например, /etc/systemd/system.confс помощью DefaultStartLimitIntervalSec(и аналогичных) параметров. Тем не менее, они часто не устанавливаются и используются скомпилированные значения по умолчанию. См man systemd-system.

— Свен

@Sven Где находится сервисный файл?

— Пользователь

2

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

Я закомментировал bantime по умолчанию и вставил альтернативный встроенный **bantime = 7200 #3600**

Я также добавил новый раздел [sasl] , который включал имя фильтра, которое изменилось по сравнению с приведенным в статье, за которой я следовал.

Вместо ошибки в одном из них, fail2ban отказался перезагружаться, давая

запрос на запуск службы повторен слишком быстро, отказ в запуске

Только когда я закомментировал раздел [sasl], я получил ошибку, которая ссылалась на недопустимое время запрета, из которого я понял, что он не может справиться со встроенными комментариями.

Когда я исправил это и раскомментировал новый раздел [sasl], я получил ошибку, что фильтр не найден. Замена правильно названного фильтра привела к перезагрузке fail2ban, как и ожидалось.

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

— MickG
источник

0

Один быстрый и грязный способ, который я только что использовал для этой же проблемы, - это создание сценария оболочки bash, который спит, чтобы служба не запускалась так быстро. Работает для меня, так как мне не нужны немедленные перезапуски ..

/root/sleep_and_start_autossh.sh

    /bin/bash -e
    sleep 200
    /usr/bin/autossh args...

/etc/systemd/system/autossh.service

    StartLimitIntervalSec=120 # this didn't seem to do much for me.
    #ExecStart=/usr/bin/autossh args ...
    ExecStart=/root/sleep_and_start_autossh.sh

— deploycat
источник

Вам нужно понизить, StartLimitIntervalSec чтобы избежать удушения, или установить его на 0, чтобы отключить. Прочтите документацию по systemd.

— Владимир Пантелеев

0

Вы не указываете, какой сервис не запускается с этой ошибкой.

У меня была эта проблема fail2ban, и, как и в ответе MickG , ошибка фактически была в моей конфигурации fail2ban и не имела ничего общего с конфигурацией службы systemd.

Решение fail2ban - запустить его с

fail2ban-client -x start

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

После исправления ошибки конфигурации сервис снова может быть остановлен или (перезапущен) с помощью systemd.

— mivk
источник