redémarrage automatique du service systemd après StartLimitInterval


33

Je veux que mon service systemd soit redémarré automatiquement en cas d'échec. De plus, je veux limiter le taux de redémarrage. Je souhaite autoriser un maximum de 3 redémarrages dans un délai de 90 secondes. Par conséquent, j'ai fait la configuration suivante.

[Service]
Redémarrer = toujours
StartLimitInterval = 90
StartLimitBurst = 3

Maintenant, le service est redémarré en cas d'échec. Après 3 échecs / redémarrages rapides, il ne redémarre plus comme prévu. Maintenant, je m'attendais à ce que systemd démarre le service après le délai d'expiration (StartLimitInterval). Mais le systemd ne démarre pas automatiquement le service après le délai d'attente (90 secondes), si je redémarre manuellement le service après le délai d'attente, il fonctionne. Mais je veux que systemd démarre automatiquement le service après StartLimitInterval. Veuillez me faire savoir comment réaliser cette fonctionnalité.


3
J'ai écrit un article qui explique comment créer un service et comment éviter ce problème particulier: Création d'un service Linux avec systemd .
Benjamin

2
Je pense que vous cherchez StartLimitIntervalSec, non StartLimitInterval.
Marc Tamsky

Réponses:


30

Pour redémarrer un service 3 fois à 90 secondes d'intervalle, incluez les lignes suivantes dans votre fichier de service systemd:

Restart=always
RestartSec=90
StartLimitInterval=400
StartLimitBurst=3

Cela a fonctionné a fonctionné pour moi pour un service qui exécute un script en utilisant «Type = inactif». Notez que «StartLimitInterval» doit être supérieur à «RestartSec * StartLimitBurst» sinon le service sera redémarré indéfiniment.

Il m'a fallu un certain temps avec beaucoup d'essais et d'erreurs pour comprendre comment systemd utilise ces options, ce qui suggère que systemd n'est pas aussi bien documenté qu'on pourrait l'espérer. Ces options fournissent efficacement le temps de cycle de relance et le nombre maximal de relances que je recherchais.


Cela devrait être marqué comme réponse acceptée ...
Jeff

ne trouve pas de StartLimitInterval=directive dans mon dernier ubuntu 18 ...
mèche

10

Le comportement que vous décrivez est conforme à la documentation:

StartLimitInterval =, StartLimitBurst = Configurer la limitation du taux de démarrage du service. Par défaut, les services démarrés plus de 5 fois en 10 secondes ne sont plus autorisés à démarrer jusqu'à la fin de l'intervalle de 10 secondes. Avec ces deux options, cette limitation de débit peut être modifiée. Utilisez StartLimitInterval = pour configurer l'intervalle de vérification (par défaut, DefaultStartLimitInterval = dans le fichier de configuration du gestionnaire, défini sur 0 pour désactiver tout type de limitation de débit). Utilisez StartLimitBurst = pour configurer le nombre de démarrages par intervalle autorisés (par défaut, DefaultStartLimitBurst = dans le fichier de configuration du gestionnaire). Ces options de configuration sont particulièrement utiles en conjonction avec Restart =; cependant, ils s'appliquent à toutes sortes de démarrages (y compris manuels), pas seulement ceux déclenchés par la logique Restart =.Notez que les unités configurées pour Restart = et qui atteignent la limite de démarrage ne sont plus tentées de redémarrer; cependant, ils peuvent toujours être redémarrés manuellement ultérieurement, à partir de ce moment, la logique de redémarrage est à nouveau activée. Notez que systemctl reset-failed entraînera le vidage du compteur de taux de redémarrage d'un service, ce qui est utile si l'administrateur souhaite démarrer manuellement un service et que la limite de démarrage interfère avec cela.

J'essaie toujours de trouver un moyen d'accomplir le comportement que vous désirez.


C'est plus un commentaire qu'une réponse comme vous le dites.
Dave M

exactement ce dont j'avais besoin, ty
Some Linux Nerd

Selon la documentation que vous avez liée, cela ne devrait-il pas être StartLimitIntervalSec=(et DefaultStartLimitIntervalSec=)? Notez l'ajout de Secaux deux noms de paramètres.
Doktor J

6

Quelques années plus tard et avec systemd 232, il ne fonctionne plus comme décrit dans la question et dans les réponses de 2016. Le nom de l'option StartLimitIntervalSecet les sections ont changé. Il doit maintenant ressembler à cet exemple:

[Unit]
StartLimitBurst=5
StartLimitIntervalSec=33

[Service]
Restart=always
RestartSec=5
ExecStart=/bin/sleep 6

Cela fera 5 redémarrages en 30 secondes (5 * 6) plus un redémarrage en 33 secondes. Nous avons donc 6 redémarrages en 33 sec. Cela dépasse la limite de 5 redémarrages en 33 sec. Les redémarrages s'arrêteront donc à 5 coups après environ 31 secondes.


1
Il semble qu'il StartLimitIntervalsoit toujours pris en charge, s'il n'est pas documenté, dans la Servicesection. Mais le nouveau, préféré StartLimitIntervalSecne fonctionne qu'en Unit.
Danek Duvall

1

Vous pouvez configurer OnFailurepour démarrer un autre service en cas d'échec. Dans le service en cas d'échec, vous pouvez exécuter un script qui attend puis redémarre votre service.

Pour un exemple sur la façon de configurer cela, voir Courriel d'état Systemd en cas de panne d'unité et modifiez-le pour redémarrer le service à la place.


1

Vous pouvez utiliser StartLimitAction=reboot. Cela redémarrera le système après StartLimitInterval.

StartLimitAction = Configurez l'action à entreprendre si la limite de débit configurée avec StartLimitInterval = et StartLimitBurst = est atteinte. Prend un de aucun, redémarrage, redémarrage forcé ou redémarrage immédiat. Si aucun n'est défini, l'atteinte de la limite de vitesse ne déclenchera aucune action en plus du fait que le démarrage ne sera pas autorisé. reboot provoque un redémarrage suivant la procédure d'arrêt normale (c'est-à-dire équivalent au redémarrage de systemctl). reboot-force provoque un redémarrage forcé qui mettra fin à tous les processus de force mais ne devrait entraîner aucun système de fichiers sale lors du redémarrage (c'est-à-dire équivalent à systemctl reboot -f) et reboot-immediate provoque l'exécution immédiate de l'appel système reboot (2), ce qui pourrait entraîner dans la perte de données. Par défaut à aucun.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.