StartLimitIntervalSec et StartLimitBurst de Systemd ne fonctionnent jamais


12

J'ai essayé de limiter le nombre de redémarrages d'un service (dans un conteneur). La version du système d'exploitation est centos-release-7-5, le fichier de service est à peu près comme ci-dessous (supprimé certains paramètres pour faciliter la lecture). Cela devrait être assez simple, comme l'ont souligné certains autres messages (limite de redémarrage 1 après défaillance du serveur, limite de redémarrage 2 après dépassement de la pile). Pourtant, StartLimitBurst et StartLimitIntervalSec ne fonctionnent jamais pour moi.

J'ai testé de plusieurs façons: (1) Je vérifie le PID du service, tue le service avec "kill -9 ****" plusieurs fois. Le service est toujours redémarré après 20s! (2) J'ai également essayé de gâcher le fichier de service, de ne jamais exécuter le conteneur. Pourtant, cela ne fonctionne pas, le fichier de service continue de redémarrer.

Une idée?

[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

2
C'est plus important que quelqu'un qui oublie de taper "Sec", comme le montrent les réponses. Je ne pense pas qu'il soit utile de clore une telle question, qui a été posée avec autant de détails que nous voulons.
sourcejedi

Réponses:


21

StartLimitIntervalSec=a été ajouté dans le cadre de systemd v230. Dans systemd v229 et inférieur, vous ne pouvez utiliser que StartLimitInterval=. Vous devrez également mettre StartLimitInterval=et StartLimitBurst=dans la [Service]section - pas la [Unit]section.

Pour vérifier votre version systemd sur CentOS, exécutez rpm -q systemd.

Si jamais vous passez à systemd v230 ou supérieur, les anciens noms de la [Service]section continueront de fonctionner.

Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html

Vous pouvez avoir ce problème sans voir aucune erreur, car systemd ignore les directives inconnues. systemd suppose que de nombreuses directives plus récentes peuvent être ignorées et autoriser l'exécution du service.

Il est possible de vérifier manuellement un fichier d'unité pour les directives inconnues. Au moins, il semble fonctionner sur un système récent:

$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'

C'est intéressant. Vous suggérez de mettre StartLimitBurstdans la section [Service], mais la documentation indique qu'il devrait être dans la section [Unit]. freedesktop.org/software/systemd/man/systemd.unit.html StartLimitIntervalSec=interval, StartLimitBurst=burst Configure unit start rate limiting. Units which are started more than burst times within an interval time interval are not permitted to start any more.
Ikrom

1
@Ikrom Dans systemd v229 et inférieur
sourcejedi

@sourcejedi Merci! Je viens de vérifier systemd sur mon centos 7 /usr/lib/systemd/systemd --versionet c'était la v219. J'ai besoin de prendre soin de la version systemd.
Ikrom

+10 si je pouvais. J'ai déjà cherché cette solution plusieurs fois (et j'ai été mal à googler apparemment). Aussi nouveau pour moi systemd-analyze. Je vous remercie!
JCotton

Il semble que cela systemd-analyzene fonctionne que pour les fichiers de service déjà installés, pas sur (disons) un fichier local que vous essayez d'écrire mais pas encore installé. (Du moins, c'est ce qui semble être le cas sur la v219 dans mes tentatives d'utilisation.) Si c'est vrai, cela pourrait valoir la peine de le mentionner dans cette réponse.
mhucka

5

Je pense avoir trouvé le problème. Tous les documents en ligne suggèrent que tous les paramètres sont dans le fichier UNIT (fichier d' unité systemd ), mais toujours dans mon système (centos 7.5), ils sont dans le fichier de service. Outre le nom est "StartLimitInterval", pas "StartLimitIntervalSec".

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.