Um serviço não arranca no meu VPS: como ler o systemctl status

Quando um serviço falha ao arrancar, a resposta está em dois comandos: systemctl status nome-do-servico e journalctl -u nome-do-servico -n 50 --no-pager. O primeiro diz que falhou e com que código; o segundo mostra as últimas linhas que o próprio serviço escreveu, onde vem a razão. Isto vale para o nginx, o Apache, a base de dados, o SSH e qualquer coisa gerida pelo systemd. Num VPS não gerido, diagnosticar e corrigir é consigo.

Ler o estado

1 Pergunte pelo estado. sudo systemctl status nginx (troque pelo nome do serviço). Procure três coisas: a linha Active: (“active (running)” está bem; “failed” ou “activating” a repetir-se, não), o código de saída em status=, e as últimas linhas de registo no fim.
2 Leia mais registo. sudo journalctl -u nginx -n 50 --no-pager. Se o problema é depois de um arranque, acrescente -b para ficar só com o arranque actual.
3 Teste a configuração com a ferramenta do próprio programa antes de reiniciar: nginx -t, apache2ctl configtest, sshd -t. Dizem a linha e o ficheiro com o erro.
4 Corrija e arranque. sudo systemctl restart nginx. Confirme com systemctl status.
5 Garanta que volta sozinho depois de um reinício. systemctl is-enabled nginx deve responder “enabled”; senão, sudo systemctl enable nginx. É a causa de “o site não voltou depois de reiniciar”, descrita em erros comuns de VPS e Cloud.

O que as mensagens costumam querer dizer

O que lê Causa e primeiro passo
Address already in use / bind() failed Outro programa tem a porta. sudo ss -tlnp | grep :80 mostra quem. Pare esse, ou mude a porta de um deles.
status=203/EXEC O systemd não conseguiu executar o programa: o caminho em ExecStart está errado, ou o ficheiro não é executável. Use o caminho completo.
Permission denied O utilizador do serviço não lê um ficheiro ou uma pasta, ou não pode escrever no registo. Veja permissões de ficheiros; no AlmaLinux ou Rocky pode ser o SELinux: SELinux e AppArmor.
Syntax error / unknown directive Erro num ficheiro de configuração. A mensagem traz o ficheiro e a linha.
Killed / code=killed, signal=KILL Quase sempre falta de memória: o OOM killer.
No space left on device Disco ou inodes cheios: o que enche o disco.
start-limit-hit / Start request repeated too quickly O systemd desistiu depois de falhas seguidas. Corrija a causa e depois sudo systemctl reset-failed nome.
Dependency failed Um serviço de que este depende falhou. Veja primeiro esse (systemctl --failed lista todos).
Não repita restart às cegas. Cada tentativa falhada conta para o limite do systemd e acaba num “start-limit-hit”, que esconde a causa original no meio de repetições. Leia o primeiro erro do registo, não o último.
Mexeu num ficheiro de serviço do systemd? Tem de correr sudo systemctl daemon-reload para o systemd o reler. Sem isso, o restart usa a versão antiga.
Se perdeu o SSH e não consegue ver nada disto, a consola do painel entra sem passar pela rede: perdi o acesso SSH ao servidor.

O servidor não responde nem na consola do painel? Isso é do nosso lado, e vemos já.

Abrir um pedido de suporte

VEJA TAMBÉM

Executar o seu programa como serviço do systemd

Onde estão os registos num VPS Linux

Falta de memória: o OOM killer

Erros comuns de VPS e Cloud

PRODUTO RECOMENDADO

Servidor VPS com acesso root

Recursos só seus, o sistema que escolher, reinstalação quando quiser. desde $8.40/mês (plano de 3 anos, com cupom)

Ver planos
  • 0 Usuários acharam útil
Esta resposta lhe foi útil?