StartLimitIntervalSec e StartLimitBurst do Systemd nunca funcionam

Tentei restringir o número de um serviço (em um contêiner) reiniciado. A versão do sistema operacional é centos-release-7-5, o arquivo de serviço está praticamente como abaixo (foram removidos alguns parâmetros para facilitar a leitura). Deve ser bem simples, como algumas outras postagens apontaram (Limite 1 de reinicialização após falha do servidor, Limite 2 de reinicialização pós-estouro de pilha). No entanto, StartLimitBurst e StartLimitIntervalSec nunca funcionam para mim.

Eu testei de várias maneiras: (1) verifico o serviço PID, mato o serviço com "kill -9 ****" várias vezes. O serviço sempre é reiniciado após os 20 anos! (2) Eu também tentei atrapalhar o arquivo de serviço, fazer com que o contêiner nunca seja executado. Ainda assim, ele não funciona, o arquivo de serviço continua sendo reiniciado.

Qualquer ideia?

[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

Isso é mais significativo do que alguém esquecendo de digitar "Sec", como mostra as respostas. Não creio que seja útil encerrar essa pergunta, que foi feita com muitos dos detalhes que queremos.

— sourcejedi

Respostas:

StartLimitIntervalSec=foi adicionado como parte do systemd v230. No systemd v229 e abaixo, você pode usar apenas StartLimitInterval=. Você também precisará colocar StartLimitInterval=e StartLimitBurst=na [Service]seção - não na [Unit]seção.

Para verificar sua versão do systemd no CentOS, execute rpm -q systemd.

Se você atualizar para o systemd v230 ou superior, os nomes antigos na [Service]seção continuarão funcionando.

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

Você pode ter esse problema sem ver nenhum erro, porque o systemd ignora diretivas desconhecidas. O systemd assume que muitas diretivas mais recentes podem ser ignoradas e ainda permitem a execução do serviço.

É possível verificar manualmente um arquivo de unidade em busca de diretivas desconhecidas. Pelo menos, parece funcionar no systemd recente:

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

— sourcejedi
fonte

Isso é interessante. Você sugere colocar StartLimitBurstna seção [Serviço], mas a documentação diz que deve estar na seção [Unidade]. 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 No systemd v229 e abaixo

— sourcejedi

@sourcejedi Thanks! Acabei de verificar o systemd no meu centos 7 /usr/lib/systemd/systemd --versione foi a v219. Eu preciso cuidar da versão systemd.

— Ikrom 17/10/18

+10 se eu pudesse. Eu procurei essa solução várias vezes antes (e fui péssimo em pesquisar no Google). Também novo para mim é systemd-analyze. Obrigado!

— JCotton

Parece que systemd-analyzefunciona apenas para arquivos de serviço já instalados, não para (digamos) um arquivo local que você está tentando gravar, mas ainda não o instalou. (Pelo menos, é o que parece ser o caso da v219 em minhas tentativas de usá-lo.) Se isso for verdade, pode valer a pena mencioná-lo nesta resposta.

— mhucka 24/04

Eu acho que encontrei o problema. Todo o documento online sugere que todos os parâmetros estão no arquivo UNIT (arquivo da unidade systemd ), mas ainda no meu sistema (centos 7.5), eles estão no arquivo de serviço. Além do nome é "StartLimitInterval", não "StartLimitIntervalSec".

— batilei
fonte