Eu revisei a documentação systemd
aquihttps://www.freedesktop.org/software/systemd/man/systemd.service.html.
Afirma na ExecStartPre=,ExecStartPost=
seção
Observe que se algum dos comandos especificados em ExecStartPre=, ExecStart= ou ExecStartPost= falhar (e não for prefixado com "-", veja acima) ou expirar antes que o serviço esteja totalmente ativo, a execução continuará com os comandos especificados em ExecStopPost= , os comandos em ExecStop= são ignorados
Eu tenho uma ExecStartPre
regra sendo
ExecStartPre=/bin/false
Em ExecStopPost
eu tenho um /bin/echo "I'm at ExecStopPost"
.
O serviço parece
[Unit]
Description=Test
[Service]
Type=oneshot
ExecStartPre=/bin/echo "I'm at ExecStartPre"
ExecStartPre=/bin/false
ExecStart=/bin/echo "Running Test"
ExecStopPost=/bin/echo "I'm at ExecStopPost"
Quando ele é executado e falha, nunca vejo isso. A saída do syslog se parece com
15 de junho 20:48:01 ip-10-0-0-246 echo[8687]: Estou no ExecStartPre
15 de junho 20:48:01 ip-10-0-0-246 systemd [1]: test.service: processo de controle encerrado, código = status de saída = 1
15 de junho 20:48:01 ip-10-0-0-246 systemd[1]: Falha ao iniciar o teste.
15 de junho 20:48:01 ip-10-0-0-246 systemd[1]: test.service.service: Unidade entrou em estado de falha.
15 de junho 20:48:01 ip-10-0-0-246 systemd [1]: test.service.service: Falha no resultado 'código de saída'.
Nunca vejo meu eco.
journalctl -u test.service
claro que também tem isso como entrada.
Preciso configurar isso de maneira um pouco diferente? Ou preciso usar OnFailure
?
Preciso ser capaz de reiniciar um Conflicts=
caso de sucesso ou falha. Isso será usado em serviços oneshot acionados por temporizadores.
Ah, e isso está rodando em 16.04.6 LTS.
Responder1
Parece que oneshot
os serviços não exigem ExecStopPost
o fracasso. Este link discute issohttps://bugzilla.redhat.com/show_bug.cgi?id=1353039.
A postagem relevante é
ExecStopPost é executado somente quando a unidade transita do estado de execução (mesmo quando a unidade é interrompida) ou quando o PID principal sai com sucesso enquanto está no estado de ativação e o serviço não é do tipo bifurcação.
A diferença é que no caso de um serviço único enquanto as ações ExecStart configuradas estão em execução, o serviço ainda está no estado de ativação e não está em execução. No entanto, no caso de serviço simples, o systemd faz a transição imediata do serviço para o estado de execução, o systemctl não bloqueia e a saída 0 é retornada mesmo quando o ExecStart falha (ou seja, ExecStart=/bin/false). Portanto, o serviço oneshot deve sair corretamente para que ExecStopPost seja chamado. AFAICT, a opção RemainAfterExit não tem impacto no ExecStopPost.
A solução acabou sendo adicionar um OnFailure
para invocar os itens necessários que teriam sido chamados emExecStopPost