StartLimitIntervalSec e StartLimitBurst di Systemd non funzionano mai

Ho provato a limitare il numero di un riavvio del servizio (in un contenitore). La versione del sistema operativo è centos-release-7-5, il file di servizio è praticamente come sotto (rimosso alcuni parametri per comodità di lettura). Dovrebbe essere piuttosto semplice come alcuni altri post hanno sottolineato (limite di riavvio Post of Server Fault 1, limite di riavvio Post of Stack Overflow 2). Tuttavia StartLimitBurst e StartLimitIntervalSec non funzionano mai per me.

Ho provato con diversi modi: (1) Controllo il servizio PID, uccido il servizio con "kill -9 ****" più volte. Il servizio viene sempre riavviato dopo 20 anni! (2) Ho anche provato a rovinare il file di servizio, facendo in modo che il contenitore non funzioni mai. Tuttavia, non funziona, il file di servizio continua a riavviarsi.

Qualche 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
fonte

Questo è più significativo di qualcuno che dimentica di digitare "Sec", come mostrato dalle risposte. Non credo sia utile chiudere una domanda del genere, che è stata posta con così tanti dettagli che desideriamo.

— sourcejedi,

Risposte:

StartLimitIntervalSec=è stato aggiunto come parte di systemd v230. In systemd v229 e precedenti, è possibile utilizzare solo StartLimitInterval=. Dovrai anche inserire StartLimitInterval=e StartLimitBurst=nella [Service]sezione, non nella [Unit]sezione.

Per verificare la versione del tuo sistema su CentOS, esegui rpm -q systemd.

Se si aggiorna mai a systemd v230 o versioni successive, i vecchi nomi nella [Service]sezione continueranno a funzionare.

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

Puoi avere questo problema senza vedere alcun errore, perché systemd ignora le direttive sconosciute. systemd presume che molte direttive più recenti possano essere ignorate e comunque consentire l'esecuzione del servizio.

È possibile controllare manualmente un file di unità per direttive sconosciute. Almeno sembra funzionare su systemd recente:

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

— sourcejedi
fonte

Interessante. Si consiglia di inserire StartLimitBurstnella sezione [Servizio], ma la documentazione dice che dovrebbe essere nella sezione [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,

@Ikrom In systemd v229 e precedenti

— sourcejedi

@sourcejedi Grazie! Ho appena controllato systemd sul mio centos 7 /usr/lib/systemd/systemd --versioned era v219. Devo occuparmi della versione di systemd.

— Ikrom,

+10 se potessi. Ho cercato questa soluzione diverse volte prima (e apparentemente non sono stato bravo a cercare su Google). Anche per me è una novità systemd-analyze. Grazie!

— JCotton

Sembra che funzioni systemd-analyzesolo per i file di servizio già installati, non su (diciamo) un file locale che stai tentando di scrivere ma che non hai ancora installato. (Almeno, è quello che sembra essere il caso della v219 nei miei tentativi di usarlo.) Se questo è vero, potrebbe valere la pena menzionarlo in questa risposta.

— mhucka,

Penso di aver trovato il problema. Tutto il documento online suggerisce che tutti i parametri sono nel file UNIT ( systemd unit file ), ma ancora nel mio sistema (centos 7.5), sono nel file di servizio. Oltre al nome è "StartLimitInterval", non "StartLimitIntervalSec".

— batilei
fonte