StartLimitIntervalSec y StartLimitBurst de Systemd nunca funcionan

Traté de restringir el número de reinicio de un servicio (en un contenedor). La versión del sistema operativo es centos-release-7-5, el archivo de servicio es más o menos como a continuación (eliminó algunos parámetros para facilitar la lectura). Debería ser bastante sencillo como lo señalaron algunas otras publicaciones (límite de reinicio posterior a la falla del servidor 1, límite de reinicio posterior al desbordamiento de la pila 2). Sin embargo, StartLimitBurst y StartLimitIntervalSec nunca funcionan para mí.

Probé de varias maneras: (1) Verifico el PID del servicio, elimino el servicio con "kill -9 ****" varias veces. ¡El servicio siempre se reinicia después de los 20 años! (2) También intenté estropear el archivo de servicio, hacer que el contenedor nunca se ejecute. Aún así, no funciona, el archivo de servicio sigue reiniciando.

¿Alguna idea?

[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

linux systemd

— batilei
fuente

Esto es más significativo que alguien que olvida escribir "Sec", como se muestra en las respuestas. No creo que sea útil cerrar esa pregunta, que se hizo con tantos detalles que queremos.

— sourcejedi

Respuestas:

StartLimitIntervalSec=fue agregado como parte de systemd v230. En systemd v229 y versiones inferiores, solo puede usar StartLimitInterval=. También necesitará poner StartLimitInterval=y StartLimitBurst=en la [Service]sección, no en la [Unit]sección.

Para verificar su versión de systemd en CentOS, ejecute rpm -q systemd.

Si alguna vez actualiza a systemd v230 o superior, los nombres antiguos en la [Service]sección continuarán funcionando.

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

Puede tener este problema sin ver ningún error, porque systemd ignora las directivas desconocidas. systemd supone que se pueden ignorar muchas directivas más nuevas y aún así permitir que se ejecute el servicio.

Es posible verificar manualmente un archivo de unidad para directivas desconocidas. Al menos parece funcionar en systemd reciente:

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

— sourcejedi
fuente

Eso es interesante. Sugiere poner StartLimitBursten la sección [Servicio], pero la documentación dice que debería estar en la sección [Unidad]. 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

@Ikrom En systemd v229 y versiones anteriores

— sourcejedi

@sourcejedi Gracias! Acabo de comprobar systemd en mi centos 7 /usr/lib/systemd/systemd --versiony fue v219. Necesito cuidar la versión systemd.

— Ikrom

+10 si pudiera. He buscado esta solución varias veces antes (y aparentemente he tenido problemas para buscar en Google). También nuevo para mí es systemd-analyze. ¡Gracias!

— JCotton

Parece que systemd-analyzesolo funciona para archivos de servicio ya instalados, no en (digamos) un archivo local que está intentando escribir pero que aún no ha instalado. (Al menos, ese es el caso en v219 en mis intentos de usarlo). Si eso es cierto, podría valer la pena mencionarlo en esta respuesta.

— mhucka

Creo que encontré el problema. Todo el documento en línea sugiere que todos los parámetros están en el archivo UNIT (archivo de unidad systemd ), pero aún en mi sistema (centos 7.5), están en el archivo de servicio. Además el nombre es "StartLimitInterval", no "StartLimitIntervalSec".

— batilei
fuente