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?
Odpowiedzi:
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.
StartLimit...opcje mogą nie być tam i po prostu użyć domyślnego (5 ponowne uruchomienie w 10 sek).
/etc/systemd/system.confpomocą DefaultStartLimitIntervalSec(i podobnych) opcji. Jednak często nie są one ustawione i używane są domyślne wartości wkompilowane. Zobaczyć man systemd-system.
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
StartLimitIntervalSec aby uniknąć dławienia, lub ustawić na 0, aby wyłączyć. Przeczytaj dokumentację systemową.
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.