Um serviço não inicia ou uma função falha? O estado e os registos do momento ajudam antes de um reinício alterar os indícios. Este guia aplica-se a sistemas com systemd. example.service representa o serviço realmente afetado.
Passo a passo
- Registe hora, fuso horário e função afetada. Descubra o nome exato da unidade na documentação da aplicação ou com
systemctl list-units --type=service --all. Os nomes variam entre distribuições. - Leia
systemctl status example.service --no-pager --full. Distinga Loaded, Active e erros concretos. ‘enabled’ indica ativação no arranque, não prova funcionamento correto neste momento. - Leia
journalctl -u example.service -b -n 100 --no-pager. Limita o resultado ao arranque atual e às últimas 100 entradas correspondentes. Num incidente anterior, esse limite pode excluir as mensagens necessárias. - Se necessário, use
journalctl -u example.service --since '2026-09-16 12:00:00' --until '2026-09-16 12:30:00' --no-pager, substituindo ambas as horas. Verifique o fuso do sistema. Leia também mensagens imediatamente anteriores à falha. - Para um serviço de utilizador, use
systemctl --user status example.serviceejournalctl --user -u example.servicena conta afetada. Entradas ausentes também podem resultar de permissões insuficientes, outros ficheiros de registo ou retenção expirada.
Verificar o resultado
Registe o primeiro erro concreto, hora e estado do serviço. Verifique separadamente a função real: ‘active’ não prova um início de sessão, pedido ou processamento bem-sucedido. Defina o próximo teste direcionado, não uma sequência de reinícios aleatórios.
Reverter e limitações
Os comandos apenas leem e não alteram o serviço. Antes de reiniciar, alterar configuração ou usar reset-failed, esclareça impacto e recuperação. Os registos podem conter dados confidenciais; partilhe só excertos necessários e limpos.