Eu tenho um backup.service chamado a cada hora por um backup.timer . Infelizmente, o script de backup em execução no contêiner pode concluir com êxito, mas com avisos retornando um código de saída diferente de zero. Portanto, embora tudo possa ter funcionado, o contêiner pára com um código de saída diferente de zero. Então a unidade entra no estado failed em frota.
E, nesse caso, parece que o temporizador não iniciará esta unidade novamente, embora eu não tenha encontrado nada nos documentos do sistema dizendo isso.
Para deixar claro: É perfeitamente aceitável para mim que o contêiner pare com um código de saída diferente de zero. Mas o meu temporizador não funciona.
Agora eu poderia exagerar esse script em outro que é então chamado de ponto de entrada do docker. Mas terei que ter certeza de que a saída em STDOUT e STDERR seja mantida de alguma forma.
Eu também poderia executar sudo systemctl reset-failed depois que a unidade falhou, mas isso parece ser um pouco hacky para mim ... (Eu tentei isso e, nesse caso, o timer executou a unidade novamente, mas não funciona como ExecStopPost-Task no arquivo de serviço)
Existe alguma maneira melhor de garantir que uma unidade
Você poderia prefixar seu comando com - e, em seguida, systemd ignorará a falha e não colocará a unidade em um estado com falha. Então, ao invés de
ExecStart=/path/to/your/command
Tente
ExecStart=-/path/to/your/command
Consulte a página do manual systemd para saber mais.
Caso você queira ignorar alguns valores de retorno, mas ainda queira que alguns outros contam como erros do systemd, você pode especificá-los na seção [Service] do seu arquivo .service como uma lista separada por espaço para SuccessExitStatus , RestartPreventExitStatus e RestartForceExitStatus . Estes também levam nomes de sinal.
Referência: man 5 systemd.service