Um serviço systemd acaba de falhar e você já possui seu nome, mas o log não é suficiente para identificar o processo que realmente parou. Antes de reiniciar a unidade ou modificar sua configuração, registre a hora do incidente e, em seguida, procure o core dump associado com coredumpctl.
Antes do primeiro comando, verifique os seguintes pontos:
- a unidade systemd em questão é conhecida;
- a hora aproximada da falha está disponível;
- você possui os direitos necessários para ler o log e o dump;
- o arquivo não deve sair da máquina nem ser compartilhado como está.
Começar pela hora e pelo processo da falha
Exiba as entradas disponíveis sem abrir um pager:
coredumpctl --no-pager listO comando exibe especialmente TIME, o PID, o usuário, o sinal, o estado do armazenamento e o caminho do executável. Lembre-se da linha cuja hora corresponde à parada do serviço. O PID permite evitar confusões entre dois processos com nomes semelhantes.
A coluna COREFILE indica o próximo passo possível. present sinaliza um arquivo acessível, enquanto journal indica um conteúdo armazenado no log. missing significa que a entrada ainda existe, embora o arquivo tenha desaparecido. Um valor none, error ou truncated limita a análise. O log pode, portanto, manter o registro de uma falha após a exclusão do arquivo associado, especialmente em /var/lib/systemd/coredump.
Não inicie ainda coredumpctl debug. O comando abre um depurador no dump selecionado, sem explicar automaticamente a causa nem restaurar o serviço.
ler um dump direcionado com coredumpctl info
Uma vez que o PID foi registrado, solicite os metadados dessa entrada:
coredumpctl info <PID>Se a lista fornecer um caminho de executável utilizável, direcione para esse caminho:
coredumpctl info /usr/bin/nome-executavelSubstitua os valores entre os sinais de menor e maior pelos da sua saída. O comando exibe o PID, o sinal, o carimbo de data/hora, a linha de comando, o executável e o tamanho ocupado. Ele também pode revelar a unidade systemd através do campo Unit, assim como o caminho de armazenamento e seu status.
O campo Unit relaciona o dump ao diagnóstico systemd. Verifique se corresponde ao serviço que falhou e se a hora concorda com o sintoma observado. Um PID sozinho não é suficiente se várias execuções ocorreram rapidamente. Um usuário sem acesso total ao log também pode ver apenas uma parte das entradas, muitas vezes aquelas de seus próprios processos.
Cruzando o dump com o log da unidade
Depois de recuperar o nome exato da unidade e a hora da falha, releia uma janela curta em torno desse instante:
journalctl -u nome-unidade --since "10 minutes ago" --until "now"Para um incidente mais antigo, substitua a janela relativa por dois carimbos de data/hora que delimitam aquele exibido por coredumpctl info. O log deve então mostrar a parada do processo, o código de saída ou o sinal, as tentativas de reinicialização e as mensagens escritas logo antes da falha.
O contador de falhas não fornece a causa. Se a unidade continuar marcada como failed, o guia dedicado ao systemctl reset-failed lembra a diferença entre o estado monitorado pelo systemd e o erro que aparece no log. Para ler os eventos que precedem a falha, seu log de serviço com journalctl fornece os filtros adequados.
Se o log da unidade não for suficiente e as mensagens mencionarem um driver, um disco ou o núcleo, consulte também as mensagens do núcleo com dmesg. Essa verificação serve para confirmar um incidente de baixo nível, sem substituir a leitura do serviço.
Manter os core dumps em um perímetro controlado
Um core dump pode conter uma porção da memória do processo no momento da falha. Dependendo da aplicação, essa memória pode incluir dados em processamento, identificadores, tokens ou fragmentos de configuração. Trate o arquivo como um dado sensível, mesmo que seu nome pareça um simples artefato técnico.
A documentação oficial do coredumpctl distingue a leitura das metadados, a extração com dump e a abertura de um depurador com debug. Em uma máquina de produção, pare após info enquanto o perímetro de análise, os direitos de acesso e o armazenamento de trabalho não estiverem validados. Uma exportação improvisada ou o envio do arquivo a um terceiro pode expor muito mais do que o nome do serviço que falhou.
Se coredumpctl estiver ausente ou se a lista permanecer vazia, o próximo passo depende da distribuição e sua política de coleta do systemd-coredump. Verifique essa política com a documentação do seu sistema antes de modificar a produção.