Diagnosticar um servidor SUSE que trava na tela de desligamento do systemd.

Se o SUSE Linux Enterprise Server travar durante o desligamento do systemd, identifique a unidade com uma tarefa de parada em execução ou inspecione as mensagens finais da inicialização anterior e, em seguida, corrija essa unidade ou sua dependência. Uma unidade é um recurso gerenciado pelo systemd, como um serviço ou um ponto de montagem; uma tarefa de parada é a solicitação do systemd para encerrar uma unidade. Não reduza um tempo limite global nem force o desligamento como primeira solução, pois um serviço ou sistema de arquivos ainda pode estar fechando arquivos ou gravando dados.

Este passo a passo segue a documentação do SLES 15 SP7, verificada em outubro de 2026. A política de parada exata depende do fornecedor do serviço e do armazenamento; portanto, utilize as orientações deles para quaisquer alterações específicas da unidade.

1. Observe o desligamento com segurança.

Passo 1: Registre a mensagem exata e aguarde por evidências úteis.

Se o console exibir a mensagem “Uma tarefa de parada está em execução para …” com uma contagem regressiva, anote o serviço ou ponto de montagem especificado e se o temporizador foi alterado. Isso significa que o systemd está aguardando a conclusão da operação de parada dessa unidade, e não necessariamente que o sistema operacional travou; bancos de dados e armazenamento remoto podem precisar de tempo para serem encerrados corretamente.

Observe através de um console remoto ou serial, ou outro terminal disponível. Evite comandos de reinicialização ou de energia enquanto houver gravações em andamento. Se o sistema parar de responder, anote a última linha visível e continue após a inicialização.

2. Encontre a unidade que está aguardando.

Etapa 2: Inspecione os trabalhos do systemd para verificar se a máquina ainda aceita comandos.

Se o SSH ou um segundo terminal ainda funcionar, pergunte ao systemd quais tarefas estão em execução ou aguardando e, em seguida, verifique a unidade nomeada na tela:

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

Substitua SERVICEpelo nome real da unidade. Uma tarefa de parada em execução restringe a busca, mas não explica por que o processo não foi encerrado. Leia o status e os logs antes de alterar a configuração. Se o systemd não responder mais, não cancele tarefas indiscriminadamente; inspecione o registro anterior após o host retornar.

3. Use a inicialização anterior para identificar a causa.

Passo 3: Leia o final do diário da inicialização anterior.

O diário é o registro indexado do systemd de mensagens do kernel, serviços e sistema. Após a próxima inicialização bem-sucedida, liste as inicializações registradas e inspecione o final da anterior:

sudo journalctl --list-boots
sudo journalctl -b -1 -e

Procure pela última mensagem "Parando", um tempo limite, novas tentativas ou um dispositivo ou ponto de montagem nomeado. A última linha é apenas uma pista: a ordem de desligamento pode deixar outra unidade em espera. Compare os registros de data e hora e as mensagens próximas.

Etapa 4: Filtre os registros do serviço suspeito

Quando a tela ou o registro de eventos mencionar um serviço, consulte apenas as entradas de inicialização anterior dessa unidade. Analise também a configuração carregada.

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

Verifique se há um ExecStopscript personalizado, um script que aguarda indefinidamente, um processo filho persistente ou um erro de aplicativo em seu gancho de desligamento. Para unidades de fornecedores, compare o pacote e a configuração com as orientações de suporte antes de editar.

Etapa 5: Verifique as montagens e o armazenamento somente quando as evidências apontarem para isso.

Se o diário mencionar uma montagem, dispositivo ou sistema de arquivos remoto, inspecione a tabela de montagem e a entrada correspondente em /etc/fstab:

sudo findmnt --verify --verbose

Verifique se uma dependência remota NFS, CIFS, iSCSI ou outra está acessível e é esperada durante o desligamento. Remova uma entrada de montagem obsoleta somente após confirmar que ela não está em uso. Não force a desmontagem de um sistema de arquivos ativo apenas com base em uma reinicialização lenta.

4. Corrija a causa sem escondê-la.

Etapa 6: Repare o serviço ou ajuste apenas a sua política de interrupção documentada.

Para um serviço que não é encerrado, corrija primeiro o script de desligamento, a configuração do aplicativo ou o problema do pacote. Um valor padrão por unidade sudo systemctl edit SERVICE.serviceé armazenado /etc/systemd/system/sem a necessidade de editar o arquivo do fornecedor. Consulte a documentação da SUSE TimeoutSecpara iniciar ou parar o serviço; use um valor aprovado pelo fornecedor para essa carga de trabalho.

Após uma edição documentada, recarregue as definições de unidade do systemd com `systemctl reload` sudo systemctl daemon-reloade inspecione o resultado com `systemctl inspect` sudo systemctl cat SERVICE.service. Um tempo limite maior pode permitir que um desligamento legítimo seja concluído, mas também pode prolongar uma reinicialização com falha. Um tempo limite menor pode encerrar um serviço antes que ele limpe o estado. Não altere os valores padrão globais para ocultar o defeito de uma unidade.

Etapa 7: Guarde os registros para o próximo incidente.

Por padrão, o SLES armazena dados de diário em um diretório /run/log/journal/, e esse diretório volátil é apagado na reinicialização. Se journalctl -b -1não houver entradas de inicialização anteriores, habilite o armazenamento persistente do diário para diagnósticos futuros.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

Os logs persistentes utilizam espaço em /var/log /var; a SUSE observa que o journal pode usar até 10% desse sistema de arquivos por padrão. Verifique o espaço livre e o período de retenção, especialmente em /varvolumes pequenos.

5. Verifique a próxima reinicialização planejada.

Etapa 8: Confirme se a parada foi concluída e se o servidor voltou a funcionar.

Após corrigir a causa suspeita, agende uma reinicialização controlada com acesso ao console. Depois que a máquina retornar, inspecione as mensagens finais da inicialização anterior e verifique o estado atual do serviço:

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

O problema é resolvido quando o servidor é desligado sem aguardar na mesma unidade, inicializa normalmente e o serviço ou a montagem funciona. Se os logs terminarem abruptamente ou mostrarem erros de kernel, controlador ou hardware, preserve-os e investigue com a SUSE ou o fornecedor do hardware em vez de ajustar os tempos limite.

Para obter detalhes sobre os comandos, consulte o guia do systemd do SLES 15 SP7 e o guia da SUSE sobre journals persistentes e filtros journalctl . Essas etapas identificam possíveis bloqueadores; a solução correta, seja por meio de serviço, sistema de arquivos ou hardware, depende da unidade identificada pelos logs da máquina.