it-swarm.com.de

Die Servicestartanforderung wurde zu schnell wiederholt und weigerte sich, das Startlimit zu erreichen

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 immer wieder neu gestartet wird. Aber wann genau weigert es sich, neu zu starten? Gibt es ein Limit oder eine Zahl, die es definiert?

Darüber hinaus, was macht too quickly genau gemein, ist es eine Begrenzung der Anzahl von Neustarts in einem bestimmten Zeitraum?

29
Vikas Tiwari

Das Standardlimit besteht darin, 5 Neustarts in einem Zeitraum von 10 Sekunden zuzulassen. Wenn ein Dienst aufgrund der Konfigurationsoption Restart= In der Dienstdefinition diesen Schwellenwert überschreitet, wird nicht versucht, einen weiteren Neustart durchzuführen.

Die Raten werden mit den Optionen StartLimitIntervalSec= Und StartLimitBurst= Konfiguriert, und die Option Restart= Steuert, wann SystemD versucht, einen Dienst neu zu starten.

Weitere Informationen in man systemd.unit Und man systemd.service.

Verwenden Sie dann systemctl daemon-reload , um die Gerätekonfiguration neu zu laden.

30
Sven

Es ist erwähnenswert, dass einige Fehler diesen Fehler auslösen, während die Ursache unterschiedlich ist.

Ich habe die Standard-Bantime auskommentiert und eine alternative Inline eingefügt **bantime = 7200 #3600**

Ich habe auch einen neuen Abschnitt [sasl] hinzugefügt, der einen Filternamen enthielt, der sich von dem in dem Artikel, dem ich folgte, angegebenen Namen geändert hatte.

Anstatt sich bei beiden zu irren, weigerte sich fail2ban, neu zu starten, und gab die

servicestartanforderung zu schnell wiederholt, Fehler beim Starten verweigert

Erst als ich den Abschnitt [sasl] auskommentierte, erhielt ich einen Fehler, der sich auf eine ungültige Bantime bezog, aus der ich erfuhr, dass er keine Inline-Kommentare verarbeiten kann.

Als ich das behoben und den neuen Abschnitt [sasl] auskommentiert habe, wurde die Fehlermeldung angezeigt, dass der Filter nicht gefunden wurde. Das Ersetzen des korrekt benannten Filters führte erwartungsgemäß zu einem erneuten Laden von fail2ban.

Wenn Sie also Änderungen vornehmen und diesen Fehler erhalten, stellen Sie sicher, dass Sie die Änderungen entfernen und trotzdem denselben Fehler erhalten, bevor Sie versuchen, ein Symptom zu beheben.

2
MickG

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 Systemd-Dienstkonfiguration zu tun.

Bei fail2ban besteht die Lösung darin, damit zu beginnen

fail2ban-client -x start

daraufhin wird eine detaillierte Fehlermeldung angezeigt. Aus irgendeinem Grund, wenn systemctl start fail2ban Der eigentliche Fehler geht verloren und kann in keinem Protokoll gefunden werden.

Sobald der Konfigurationsfehler behoben ist, kann der Dienst erneut gestoppt oder mit systemd (neu) gestartet werden.

0
mivk

Eine schnelle und schmutzige Methode, die ich gerade für dasselbe Problem verwendet habe, besteht darin, ein Bash-Wrapper-Skript zu erstellen, das in den Ruhezustand versetzt wird, damit der Dienst nicht so schnell gestartet wird. Funktioniert für mich, 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
0
deploycat