Um serviço que falha em failed não precisa de um reinício imediato. 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 com falha
Este comando exibe os serviços e unidades que o systemd considera como defeituosos:
systemctl --failedAnote o nome completo, como nginx.service ou minha-aplicacao.service. Uma unidade exited não está necessariamente com defeito: alguns serviços executam uma tarefa rápida e, em seguida, 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.
Leia o estado do serviço antes de qualquer reinício
Substitua nginx pela sua unidade. A opção --no-pager imprime o resultado diretamente no terminal, evitando ficar preso no less em uma sessão SSH.
sudo systemctl status nginx --no-pagerPreste atenção especialmente 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 costumam aparecer aqui. Se o serviço inicia um binário que possui seu próprio validador, execute primeiro esse validador. Para o Nginx, por exemplo:
sudo nginx -tNão execute esse comando em uma máquina que não use Nginx. Cada serviço tem sua própria sintaxe de verificação.
Recuperar a 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 se a falha for mais antiga. Para acompanhar uma reinicialização em tempo real, utilize 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 atinge vários serviços.
Corrigir, reiniciar e depois 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 está escutando em uma porta, verifique também a porta e faça um teste a partir do cliente correto. Uma resposta active não garante que uma aplicação web, um proxy ou um banco de dados já estão aceitando requisições.
Em um serviço crítico, mantenha uma segunda sessão SSH aberta antes de um reinício e copie o erro exato em seu ticket ou suas notas. Você evitará repetir o mesmo diagnóstico no próximo incidente.