Um serviço que falha em failed não precisa de uma reinicialização imediata. Em um servidor, esse hábito às vezes apaga a mensagem que explica a falha ou reinicia um programa com uma configuração ainda inválida.
Comece identificando a unidade afetada, leia seu estado e seu log, e então corrija a causa. O reinício vem depois.
Listar as unidades realmente falhas
Este comando exibe os serviços e unidades que o systemd considera como falhos:
systemctl --failedAnote o nome completo, por exemplo nginx.service ou minha-aplicacao.service. Uma unidade exited não está necessariamente com problemas: alguns serviços executam uma tarefa curta e então param normalmente. O status failed indica que uma inicialização, um comando de controle ou um processo monitorado terminou com erro.
Para rever os serviços ativos, parados e seus estados, consulte também a lista de serviços com systemctl.
Ler o estado do serviço antes de qualquer reinicialização
Substitua nginx pela sua unidade. A opção --no-pager imprime o resultado diretamente no terminal, evitando ficar no less em uma sessão SSH.
sudo systemctl status nginx --no-pagerPreste atenção principalmente na linha Active:, no código de saída e nas últimas linhas exibidas. Uma porta já ocupada, um caminho ausente, um certificado ilegível ou uma diretiva mal escrita aparecem frequentemente aqui. Se o serviço inicia um binário que possui seu próprio validador, inicie primeiro este validador. Para Nginx, por exemplo:
sudo nginx -tNão execute este comando em uma máquina que não está usando Nginx. Cada serviço tem sua própria sintaxe de verificação.
Subir ao mensagem de erro com journalctl
systemctl status mostra apenas um extrato. O log da unidade fornece o contexto completo:
sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager-b limita a pesquisa à inicialização atual. -n 50 mantém as 50 últimas linhas, caso a falha seja mais antiga. Para acompanhar um reinício ao vivo, use sudo journalctl -fu nginx em uma segunda sessão SSH. O guia journalctl e as mensagens da última inicialização ajuda a ampliar o diagnóstico quando o erro afeta vários serviços.
Corrigir, reiniciar e verificar
Após uma modificação no arquivo de unidade ou em um drop-in do systemd, recarregue a configuração. Esta etapa não reinicia o serviço.
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failedis-active deve responder active. Se o serviço escuta em uma porta, verifique também a porta e faça um teste pelo cliente correto. Uma resposta active não garante que uma aplicação web, um proxy ou um banco de dados já aceitam requisições.
Em um serviço crítico, mantenha uma segunda sessão SSH aberta antes de uma reinicialização e copie o erro exato em seu ticket ou notas. Você evitará ter que repetir o mesmo diagnóstico no próximo incidente.