Após um serviço com falha, o que realmente faz systemctl reset-failed?

systemctl reset-failed redefine o estado de falha de uma unidade e seu contador de reinícios. O comando prepara um novo controle, mas não repara o serviço.

Quando uma unidade systemd vai para o estado failed, a tentação é executar imediatamente systemctl reset-failed. Em uma VM, computador ou servidor, este comando pode remover o estado visível sem tocar na causa da parada.

O diagnóstico começa pelo estado do serviço e seu diário. Você poderá então reconfigurar a unidade específica, verificar o resultado e tentar um início separado se o erro for compreendido.

Leia o serviço antes de redefinir seu estado

Uma unidade marcada como failed indica o estado acompanhado pelo systemd. Sozinha, ela não fornece a razão da falha. Comece pelo status e pelo diário da unidade realmente envolvida:

systemctl status meu-serviço.service
journalctl -u meu-serviço.service

O link journalctl permite encontrar a mensagem do serviço no diário. Leia-o antes de remover o estado failed, especialmente se a unidade estiver reiniciando em loop.

Para separar o estado atual, o subestado, o resultado da execução e o contador de reinícios, peça também as propriedades da unidade:

systemctl show meu-serviço.service -p ActiveState -p SubState -p Result -p NRestarts

Esses quatro valores respondem a perguntas diferentes:

• ActiveState indica o estado geral acompanhado pelo systemd.
• SubState especifica o subestado da unidade.
• Result indica o resultado da execução que levou à falha.
• NRestarts dá o número de reinícios registrados.

O comando reset-failed apaga o estado, não o erro

Após a leitura, direcione apenas para a unidade em questão:

sudo systemctl reset-failed meu-serviço.service

systemctl reset-failed <unidade> redefine o estado failed da unidade e o contador de reinícios associado à limitação de inicialização. O comando não reinicia a unidade.

Ele não modifica nem ExecStart, nem as permissões, nem as dependências, nem o binário usado pela unidade. Ele também não apaga o diário. A página do manual de systemctl descreve esse comportamento e os outros subcomandos disponíveis.

A remoção de failed pode, portanto, dar uma falsa impressão de reparo. O serviço ainda pode conter uma configuração inválida, uma dependência ausente ou um comando ExecStart que falha.

Verifique o resultado antes de uma nova inicialização

Revise as propriedades após a redefinição. O controle se concentra no estado da unidade e no contador, e não em uma saída de comando para copiar:

systemctl show meu-serviço.service -p ActiveState -p SubState -p Result -p NRestarts

Se a causa for compreendida e corrigida, a inicialização se torna uma ação distinta:

sudo systemctl start meu-serviço.service
systemctl status meu-serviço.service
journalctl -u meu-serviço.service

O status e o diário permitem verificar o estado obtido após essa inicialização. Se a unidade voltar imediatamente a falhar, pare as tentativas e corrija a causa apontada em Result ou no diário.

Recarregue os arquivos da unidade com sudo systemctl daemon-reload após a modificação de um arquivo de unidade. Esta etapa não segue automaticamente o reset-failed. A pasta dedicada aos recargas do systemd lida com esse caso separadamente.

Para um serviço iniciado por um timer, o funcionamento dos timers do systemd explica a relação entre a unidade de serviço e seu acionador. O estado redefinido não corrige nem o programa, nem a configuração, nem a dependência que causa a falha.