J'ai un service systemd qui affiche l'erreur suivante service start request repeated too quickly, refusing to start
Je comprends que le service est configuré pour redémarrer en cas d'échec et qu'il redémarre encore et encore. Mais quand exactement refuse-t-il de redémarrer? Y a-t-il une limite ou un nombre qui le définit?
De plus, qu'est-ce que cela too quicklysignifie exactement, s'agit-il d'une limite de nombre de redémarrages dans une période de temps donnée?
Réponses:
La limite par défaut est d'autoriser 5 redémarrages dans une période de 10 secondes. Si un service dépasse ce seuil en raison de l' Restart=option config dans la définition de service, il ne tentera plus de redémarrer.
Les taux sont configurés avec les StartLimitIntervalSec=et StartLimitBurst=options et les Restart=contrôles d'option lorsque systemd tente de redémarrer un service.
Plus d'informations dans man systemd.unitet man systemd.service.
Ensuite, utilisez systemctl daemon-reloadpour recharger la configuration de l'unité.
StartLimit...options peuvent ne pas être là et utiliser simplement la valeur par défaut (5 redémarrages en 10 secondes).
/etc/systemd/system.confavec les DefaultStartLimitIntervalSecoptions (et similaires). Cependant, ceux-ci ne sont souvent pas définis et les valeurs par défaut compilées sont utilisées. Tu vois man systemd-system.
Il est à noter que certains défauts semblent déclencher cette erreur, alors que la cause est différente.
J'ai commenté le bantime par défaut et inséré une alternative en ligne
**bantime = 7200 #3600**
J'ai également ajouté une nouvelle section [sasl] , qui comprenait un nom de filtre qui avait changé de celui donné dans l'article que je suivais .
Au lieu de commettre une erreur sur l'un ou l'autre, fail2ban a refusé de redémarrer, donnant
demande de démarrage du service répétée trop rapidement, refus de démarrer l'erreur
Ce n'est que lorsque j'ai commenté la section [sasl] que j'ai eu une erreur qui faisait référence à un bantime invalide, dont j'ai déduit qu'il ne pouvait pas faire face aux commentaires en ligne.
Lorsque j'ai corrigé cela et commenté la nouvelle section [sasl], j'ai reçu une erreur indiquant que le filtre était introuvable. La substitution du filtre correctement nommé a entraîné le rechargement de fail2ban comme prévu.
Donc, si vous apportez des modifications et obtenez cette erreur, assurez-vous de supprimer les modifications et d'obtenir toujours la même erreur avant d'essayer de corriger un problème.
Une manière rapide et sale que je viens d'utiliser pour ce même problème est que j'ai créé un script wrapper bash qui dort afin que le service ne démarre pas aussi rapidement. Fonctionne pour moi car je n'ai pas besoin des redémarrages immédiats ..
/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 pour éviter la limitation ou le régler sur 0 pour le désactiver. Lisez la documentation de systemd.
Vous ne spécifiez pas quel service ne démarre pas avec cette erreur.
J'ai eu ce problème avec fail2ban, et comme dans la réponse de MickG , l'erreur était en fait dans ma configuration fail2ban, et n'avait rien à voir avec la configuration du service systemd.
Avec fail2ban, la solution est de le démarrer avec
fail2ban-client -x start
qui affichera un message d'erreur détaillé. Pour une raison quelconque, lors de l'utilisation, systemctl start fail2banl'erreur réelle est perdue et ne peut être trouvée dans aucun journal.
Une fois l'erreur de configuration corrigée, le service peut à nouveau être arrêté ou (re) démarré avec systemd.