Ich habe einen systemd-Dienst, der den folgenden Fehler anzeigt service start request repeated too quickly, refusing to start
Ich verstehe, dass der Dienst so konfiguriert ist, dass er bei einem Fehler neu gestartet wird, und dass er immer wieder neu gestartet wird. Aber wann genau weigert es sich, neu zu starten? Gibt es ein Limit oder eine Anzahl, die es definiert?
Was too quicklygenau bedeutet es außerdem, dass die Anzahl der Neustarts in einem bestimmten Zeitraum begrenzt ist?
Antworten:
Standardmäßig sind 5 Neustarts in einem Zeitraum von 10 Sekunden zulässig. Wenn ein Dienst aufgrund der Restart=Konfigurationsoption in der Dienstdefinition diesen Schwellenwert überschreitet , wird kein weiterer Neustart versucht.
Die Preise sind so konfiguriert , mit den StartLimitIntervalSec=und StartLimitBurst=Optionen und die Restart=Option steuert , wenn Systemd einen Dienst neu zu starten versucht.
Mehr Infos in man systemd.unitund man systemd.service.
Verwenden Sie dann, um systemctl daemon-reloaddie Gerätekonfiguration neu zu laden.
StartLimit...Optionen sind möglicherweise nicht vorhanden und verwenden nur die Standardeinstellung (5 Neustarts in 10 Sekunden).
/etc/systemd/system.confden DefaultStartLimitIntervalSec(und ähnlichen) Optionen konfiguriert werden . Diese werden jedoch häufig nicht festgelegt und die kompilierten Standardeinstellungen werden verwendet. Sehen man systemd-system.
Es ist erwähnenswert, dass einige Fehler diesen Fehler auszulösen scheinen, während die Ursache anders ist.
Ich habe die Standard-Bantime auskommentiert und eine alternative Inline eingefügt
**bantime = 7200 #3600**
Ich fügte auch einen neuen Abschnitt [sasl] hinzu , der einen Filternamen enthielt, der sich von dem in dem Artikel geändert hatte, dem ich folgte.
Anstatt Fehler zu machen, weigerte sich fail2ban, neu zu starten, und gab das
Servicestartanforderung zu schnell wiederholt, Fehler wird nicht gestartet
Erst als ich den Abschnitt [sasl] auskommentierte, erhielt ich einen Fehler, der sich auf eine ungültige Bantime bezog, von der ich erfuhr, dass sie keine Inline-Kommentare verarbeiten kann.
Als ich das korrigierte und den neuen Abschnitt [sasl] auskommentierte, bekam ich eine Fehlermeldung, dass der Filter nicht gefunden wurde. Das Ersetzen des korrekt benannten Filters führte zu dem erwarteten erneuten Laden von fail2ban.
Wenn Sie also Änderungen vornehmen und diesen Fehler erhalten, stellen Sie sicher, dass Sie die Änderungen entfernen und dennoch denselben Fehler erhalten, bevor Sie versuchen, ein Symptom zu beheben.
Eine schnelle und schmutzige Möglichkeit, die ich gerade für das gleiche Problem verwendet habe, ist das Erstellen eines Bash-Wrapper-Skripts, das in den Ruhezustand versetzt wird, damit der Dienst nicht so schnell gestartet wird. Funktioniert bei mir, da ich keinen sofortigen Neustart benötige.
/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 die Drosselung zu vermeiden, oder setzen Sie ihn auf 0 zu deaktivieren. Lesen Sie die Systemdokumentation.
Sie geben nicht an, welcher Dienst mit diesem Fehler nicht gestartet werden kann.
Ich hatte dieses Problem mit fail2ban, und wie in der Antwort von MickG , war der Fehler tatsächlich in meiner fail2ban-Konfiguration und hatte nichts mit der Konfiguration des systemd-Dienstes zu tun.
Bei fail2ban ist die Lösung, damit zu beginnen
fail2ban-client -x start
Daraufhin wird eine detaillierte Fehlermeldung angezeigt. Aus irgendeinem Grund geht bei der Verwendung systemctl start fail2bander eigentliche Fehler verloren und kann in keinem Protokoll gefunden werden.
Sobald der Konfigurationsfehler behoben ist, kann der Dienst mit systemd wieder gestoppt oder (neu) gestartet werden.