Żądanie uruchomienia usługi powtórzyło się zbyt szybko, odmawiając uruchomienia limitu

Mam usługę systemową, która wyświetla następujący błąd service start request repeated too quickly, refusing to start

Rozumiem, że usługa jest skonfigurowana do ponownego uruchomienia w przypadku awarii i jest uruchamiana ponownie. Ale kiedy dokładnie odmawia ponownego uruchomienia? Czy istnieje limit lub liczba, która go definiuje?

Co jeszcze too quicklydokładnie oznacza, czy jest to limit liczby ponownych uruchomień w danym okresie czasu?

Domyślnym limitem jest zezwolenie na 5 restartów w okresie 10 sekund. Jeśli usługa przekroczy ten próg z powodu Restart=opcji config w definicji usługi, nie będzie podejmowała próby ponownego uruchomienia.

Stawki są skonfigurowane z StartLimitIntervalSec=oraz StartLimitBurst=opcji i Restart=kontroli rozwiązaniem, gdy Systemd próbuje ponownie uruchomić usługę.

Więcej informacji w man systemd.uniti man systemd.service.

Następnie użyj systemctl daemon-reloaddo ponownego załadowania konfiguracji urządzenia.

Warto zauważyć, że niektóre usterki wydają się rzucać ten błąd, podczas gdy przyczyna jest inna.

Skomentowałem domyślną wersję bantime i wstawiłem alternatywny wiersz **bantime = 7200 #3600**

Dodałem również nową sekcję [sasl] , która zawiera nazwę filtru, która zmieniła się od tej podanej w artykule, który śledziłem .

Zamiast błędu w którymkolwiek z nich, fail2ban odmówił ponownego uruchomienia, podając

żądanie uruchomienia usługi powtórzyło się zbyt szybko, odmawiając uruchomienia błędu

Dopiero gdy skomentowałem sekcję [sasl], dostałem błąd, który odnosi się do niepoprawnego bantime, z którego dowiedziałem się, że nie może poradzić sobie z wbudowanymi komentarzami.

Kiedy to naprawiłem i odkomentowałem nową sekcję [sasl], dostałem błąd, że filtr nie został znaleziony. Zastąpienie poprawnie nazwanego filtra spowodowało przeładowanie fail2ban zgodnie z oczekiwaniami.

Więc jeśli dokonasz zmian i pojawi się ten błąd, upewnij się, że usuwasz zmiany i nadal otrzymujesz ten sam błąd, zanim spróbujesz naprawić objaw.

Jednym z szybkich i brudnych sposobów, które właśnie wykorzystałem w przypadku tego samego problemu, jest utworzenie skryptu opakowania bash, który śpi, aby usługa nie uruchamiała się tak szybko. Działa dla mnie, ponieważ nie potrzebuję natychmiastowych restartów.

/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

Nie określasz, która usługa nie uruchamia się z tego błędu.

Miałem ten problem fail2bani tak jak w odpowiedzi MickG , błąd był w mojej konfiguracji fail2ban i nie miał nic wspólnego z konfiguracją usługi systemd.

W przypadku fail2ban rozwiązaniem jest uruchomienie go

fail2ban-client -x start

który wyświetli szczegółowy komunikat o błędzie. Z jakiegoś powodu podczas używania systemctl start fail2banrzeczywisty błąd gubi się i nie można go znaleźć w żadnym dzienniku.

Po usunięciu błędu konfiguracji usługa może zostać ponownie zatrzymana lub (ponownie) uruchomiona za pomocą systemd.