Ho un servizio systemd che visualizza il seguente errore service start request repeated too quickly, refusing to start
Comprendo che il servizio è configurato per il riavvio in caso di errore e si riavvia ancora e ancora. Ma quando rifiuta esattamente il riavvio? C'è un limite o un numero che lo definisce?
Inoltre, cosa significa too quicklyesattamente, è un limite del numero di riavvii in un determinato periodo di tempo?
Risposte:
Il limite predefinito è consentire 5 riavvii in un periodo di 10 secondi. Se un servizio supera tale soglia a causa Restart=dell'opzione di configurazione nella definizione del servizio, non tenterà di riavviare ulteriormente.
Le tariffe sono configurati con le StartLimitIntervalSec=e StartLimitBurst=opzioni ei Restart=controlli di opzione quando systemd tenta di riavviare un servizio.
Maggiori informazioni in man systemd.unite man systemd.service.
Quindi utilizzare systemctl daemon-reloadper ricaricare la configurazione dell'unità.
StartLimit...opzioni potrebbero non essere presenti e utilizzare solo l'impostazione predefinita (5 riavvii in 10 secondi).
/etc/systemd/system.confCon le DefaultStartLimitIntervalSecopzioni (e simili). Tuttavia, questi spesso non vengono impostati e vengono utilizzati i valori predefiniti compilati. Vedere man systemd-system.
Vale la pena notare che alcuni difetti sembrano gettare questo errore, mentre la causa è diversa.
Ho commentato il bantime predefinito e ho inserito un inline alternativo
**bantime = 7200 #3600**
Ho anche aggiunto una nuova sezione [sasl] , che includeva un nome di filtro che era cambiato da quello indicato nell'articolo che stavo seguendo.
Invece di errori in uno di questi, fail2ban ha rifiutato di riavviarsi, dando il
richiesta di avvio del servizio ripetuta troppo rapidamente, rifiutando di avviare l'errore
Solo quando ho commentato la sezione [sasl], ho ricevuto un errore che si riferiva a un periodo di validità non valido, dal quale ho capito che non è in grado di gestire i commenti incorporati.
Quando ho risolto questo problema e ho decommentato la nuova sezione [sasl], ho ricevuto un errore che non trovava il filtro. La sostituzione del filtro con nome corretto ha comportato il ricaricamento fail2ban come previsto.
Pertanto, se si apportano modifiche e si ottiene questo errore, assicurarsi di rimuovere le modifiche e ottenere comunque lo stesso errore prima di provare a correggere un sintomo.
Un modo rapido e sporco che ho appena usato per questo stesso problema è che ho creato uno script wrapper bash che dorme in modo che il servizio non si avvii così velocemente. Funziona per me in quanto non ho bisogno di riavvii immediati ..
/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 per evitare la limitazione, o impostarlo su 0 per disabilitare. Leggi la documentazione di systemd.
Non si specifica quale servizio non può iniziare con questo errore.
Ho avuto questo problema con fail2ban, e come nella risposta di MickG , l'errore era effettivamente nella mia configurazione fail2ban e non aveva nulla a che fare con la configurazione del servizio systemd.
Con fail2ban, la soluzione è avviarlo
fail2ban-client -x start
che visualizzerà un messaggio di errore dettagliato. Per qualche motivo, quando si utilizza systemctl start fail2banl'errore reale si perde e non si trova in alcun registro.
Una volta corretto l'errore di configurazione, il servizio può essere nuovamente arrestato o (ri) avviato con systemd.