Reinicie o serviço e confirme mesmo que ele voltou

2026-07-18

sudo systemctl restart nginx && systemctl is-active nginx reinicia o serviço e imprime uma palavra dizendo se ele está mesmo rodando. O restart fica calado quando dá certo e igualmente calado quando o processo morre um segundo depois, então a verificação precisa ser um comando próprio — e o is-active responde inactive também quando você errou o nome do unit, que é onde quase todo mundo se engana.

1. Reinicie e confira na mesma linha

clai

$ clai reinicie o docker e diga se ele voltou→ sudo systemctl restart docker && systemctl is-active dockeractive

O restart não imprime nada quando dá certo, e silêncio não prova coisa alguma. O is-active devolve uma única palavra com código de saída 0 — exatamente o que se quer depois de &&.

2. A armadilha: erro no nome do unit

clai

$ clai verifique se o serviço nosuch está rodando→ systemctl is-active nosuch.serviceinactive

Um unit que não existe responde inactive com código 4, e não "unit not found". Num script isso se lê como "o serviço está parado", quando na verdade você digitou errado. O status é honesto: Unit nosuch.service could not be found.

3. O que o status está realmente dizendo

clai

$ clai mostre o estado do serviço docker→ systemctl status docker● docker.service - Docker Application Container Engine     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)     Active: active (running) since Mon 2026-08-24 14:15:54 +07; 3 days ago Invocation: ca41df104d0f46f5a69c964621baf011TriggeredBy: ● docker.socket       Docs: https://docs.docker.com

Duas linhas carregam o sentido. Loaded diz que o arquivo do unit foi encontrado, e enabled que ele sobe no boot. Active traz o tempo de execução: se aparecem segundos e você reiniciou há um minuto, o serviço caiu e voltou sozinho.

4. Uma verificação para scripts, não para os olhos

clai

$ clai mostre o estado do docker em formato legível por máquina→ systemctl show -p ActiveState,SubState,MainPID,NRestarts dockerActiveState=activeSubState=runningMainPID=5425NRestarts=0

O show não formata nada para humanos, então sobrevive a atualizações do systemd que remexem a saída bonita. Um NRestarts subindo é o sinal mais rápido de que uma política Restart= está encobrindo um ciclo de quedas.

5. Encontre tudo que falhou

clai

$ clai mostre os serviços que falharam→ systemctl --failed  UNIT              LOAD   ACTIVE SUB    DESCRIPTION● logrotate.service loaded failed failed Rotate log files

Curto e direto. Para um unit específico, systemctl is-failed <nome> imprime failed e sai com código 0 quando ele está mesmo nesse estado.

6. Limpe o estado failed

clai

$ clai limpe o estado de falha do serviço logrotate→ sudo systemctl reset-failed logrotate.service

Enquanto o estado não for limpo, o unit continua na lista --failed e o contador StartLimitBurst pode recusar novas tentativas com "start request repeated too quickly". O reset-failed zera o contador e tira o unit da lista.

Gotchas

Silêncio depois do restart não prova nada. O systemctl restart imprime vazio tanto com o serviço saudável quanto com ele morto no primeiro segundo. A verificação é sempre outro comando.
is-active não distingue erro de digitação de serviço parado. Os dois respondem inactive. Os códigos de saída diferem — 4 para um unit inexistente — mas isso não se vê a olho nu, então recorra ao status quando a resposta surpreender.
restart não relê um arquivo de unit alterado. Depois de editar um .service é preciso sudo systemctl daemon-reload, senão o systemd sobe a versão antiga e você caça um bug numa configuração já corrigida.

Reinicie o serviço e confirme mesmo que ele voltou

1. Reinicie e confira na mesma linha

2. A armadilha: erro no nome do unit

3. O que o status está realmente dizendo

4. Uma verificação para scripts, não para os olhos

5. Encontre tudo que falhou

6. Limpe o estado failed

Gotchas

Related questions

See also