Linux / Comando journalctl: consultar logs de serviços e inicializações

O comando journalctl consulta os logs de sistema e de serviços armazenados no journal do systemd. Combine filtros de unidade, inicialização, prioridade e horário para investigar um problema sem percorrer todo o histórico disponível.

O journal é o conjunto de registros estruturados coletados pelo serviço de logs do systemd. Ele não inclui automaticamente todo arquivo de log de qualquer aplicação: a mensagem precisa ter sido encaminhada e armazenada ali. Sem argumentos, journalctl apresenta as entradas acessíveis da mais antiga para a mais recente; a permissão da conta e os dados ainda retidos limitam o resultado.

Sintaxe e preparação

journalctl [opções] [filtros]

Esta linha descreve a sintaxe: os colchetes indicam argumentos opcionais e não devem ser copiados literalmente. Os filtros selecionam registros já armazenados; uma consulta não inicia nem reinicia o serviço investigado.

Abra um terminal no sistema Linux que usa o journal do systemd. Confira a disponibilidade com command -v journalctl, a versão com journalctl --version e as opções locais com journalctl --help ou man journalctl. Uma distribuição sem esse componente, um contêiner ou um ambiente sem acesso aos arquivos do journal pode não oferecer o histórico esperado.

Uma conta comum pode ter acesso apenas a parte dos registros. Se aparecer um aviso de permissão, confirme a política de acesso do servidor e use uma conta já autorizada para a investigação. Não altere grupos, permissões ou a configuração de logs apenas para fazer os exemplos funcionarem.

Consultar erros da inicialização atual

journalctl -b -p err

A opção -b, sem outro argumento, seleciona a inicialização atual. -p err inclui o nível de erro e os níveis mais graves: err, crit, alert e emerg, prioridades numéricas de 3 a 0. Não inclui warning e não significa “somente mensagens exatamente do nível err”.

Se o resultado abrir em um paginador, use as teclas de navegação para ler e q para sair. Acrescente --no-pager quando quiser a saída diretamente no terminal. Uma consulta sem resultados só informa que não foram encontradas entradas acessíveis que correspondam aos filtros; isso não comprova que o sistema esteja saudável.

Ler registros de um serviço

journalctl -u sshd.service -n 100

Substitua sshd.service pelo nome real da unidade. Conforme a distribuição, o serviço SSH pode ter outro nome, como ssh.service; confirme-o com as consultas de unidades explicadas no guia do comando systemctl. Não adivinhe o nome a partir apenas do nome do programa.

A opção -u seleciona entradas associadas à unidade, inclusive mensagens relacionadas emitidas pelo gerenciador de serviços. Ela não é uma busca textual por “sshd” em qualquer mensagem. -n 100 limita a saída às últimas 100 entradas correspondentes disponíveis, e uma entrada pode ocupar várias linhas. Sem -b, o resultado pode abranger mais de uma inicialização armazenada; adicione esse filtro se quiser apenas a atual.

Acompanhar novas mensagens

journalctl -u sshd.service -f

Com -f, a consulta mostra inicialmente as entradas recentes e continua exibindo as novas à medida que chegam. Sem outro limite, o padrão inicial é de até dez entradas. Se não surgir nenhuma mensagem nova, a espera é normal e não demonstra que o serviço parou.

Pressione Ctrl+C para encerrar o acompanhamento. Isso encerra o leitor de logs, sem parar o serviço SSH. Evite reiniciar um serviço de acesso remoto apenas para provocar mensagens, especialmente quando ele sustenta a sua própria conexão.

Interpretar uma entrada do journal

journalctl -u sshd.service -n 3 --no-pager

Esse comando pede até três entradas recentes da unidade e desativa o paginador. O trecho abaixo é uma ilustração do formato de uma entrada, preservada do exemplo original; não é uma saída obtida neste ambiente nem uma promessa de que três linhas iguais aparecerão.

Sep 28 09:00:00 web01 sshd[1234]: Server listening on 0.0.0.0 port 22.

Leia os campos da ilustração nesta ordem:

• Sep 28 09:00:00: data e horário apresentados nesse formato. O trecho não contém ano nem fuso horário, portanto não permite deduzi-los.
• web01: nome do host que aparece no registro.
• sshd[1234]: identificador do programa e PID, isto é, identificador do processo, mostrados na entrada.
• Server listening on 0.0.0.0 port 22.: mensagem que indica escuta na porta 22 nesse exemplo. Ela não comprova que um usuário conseguiu autenticar ou que uma conexão externa consegue alcançar o servidor.

O horário, o host, o PID, a mensagem e o formato real variam conforme os registros e as opções de saída. Para diferenciar ano e fuso durante uma investigação, consulte também os formatos de saída, como --output=short-full, descritos no manual oficial de journalctl.

Delimitar o horário do problema

Use --since e --until para definir o início e o fim da janela. Por exemplo, journalctl -u sshd.service --since '2026-09-28 09:00:00' --until '2026-09-28 09:10:00' --no-pager consulta as entradas dessa unidade no intervalo especificado, incluindo os limites. As aspas mantêm cada data e horário como um único argumento.

Essas datas são exemplos fixos: troque-as pela janela real do incidente. Sem indicação explícita de fuso, esses horários são interpretados no fuso local do sistema. Compare-os com o relógio e o fuso da origem do relato; o trecho ilustrativo sem ano não estabelece que o evento ocorreu em 2026. Examine alguns minutos antes e depois para separar a primeira falha de suas consequências.

Opções principais

Investigar uma inicialização anterior

Comece por journalctl --list-boots. A lista mostra as inicializações disponíveis, seus identificadores e os horários da primeira e da última entrada de cada uma. Em seguida, use journalctl -b -1 para consultar a inicialização disponível anterior à atual ou selecione explicitamente um identificador da lista. Não presuma que todo reinício real ainda tenha registros retidos.

A disponibilidade depende do armazenamento e da retenção. Registros voláteis em /run/log/journal não sobrevivem à reinicialização; o armazenamento persistente utiliza /var/log/journal, sujeito à configuração e aos limites de retenção. Consulte a opção Storage= no manual oficial de journald.conf para entender o sistema em uso. Não assuma o mesmo padrão em todas as distribuições.

Arquivos de journal rotacionados ainda podem ser lidos enquanto estiverem disponíveis e acessíveis. A rotação, por si só, não significa que o histórico foi apagado. Se as entradas foram removidas por retenção, limpeza ou perda do armazenamento volátil, trocar os filtros não as recupera.

Quando a consulta não encontra o que você procura

1. Leia os avisos e erros do próprio comando. “Comando não encontrado” significa falta do utilitário nesse ambiente; difere de uma consulta executada sem entradas correspondentes.
2. Confira a unidade e o escopo. Uma unidade de usuário e uma unidade do sistema são contextos diferentes; confirme quando a opção --user é apropriada. Retire temporariamente filtros de prioridade ou horário excessivamente restritos, mantendo o acesso autorizado.
3. Verifique a inicialização selecionada, as datas, o fuso e a permissão de leitura. Consulte as inicializações disponíveis antes de buscar um evento anterior.
4. Confirme que a aplicação encaminhava os logs ao journal e que eles ainda estavam retidos. Um programa que grava apenas em arquivo próprio precisa ser investigado nesse destino. Para mensagens do kernel, o guia do comando dmesg explica a consulta ao buffer do kernel e suas diferenças de histórico.

Antes de compartilhar um recorte, confira tokens, nomes de usuários, endereços, caminhos e outros dados sensíveis. Preserve o original sob o controle de acesso adequado e compartilhe uma cópia com os valores sensíveis ocultados, sem eliminar o contexto necessário para interpretar o erro.

As opções --vacuum-* removem arquivos arquivados de journal e não servem apenas para filtrar a visualização. Não as execute durante uma simples consulta nem confunda investigação com limpeza de armazenamento.

No ambiente disponível para esta revisão, o Bash 5.3.9 do Git para Windows não tinha journalctl; as quatro consultas retornaram “command not found”, código 127. Assim, os comportamentos descritos foram conferidos na documentação do systemd, mas não houve leitura de journal Linux nem teste interativo de acompanhamento aqui. Confira a versão e as condições de acesso no Linux em que fará a consulta.

Pergunta frequente

Por que não aparecem os logs da inicialização anterior?

Eles podem ter sido armazenados apenas de forma volátil, removidos por retenção ou estar fora do acesso da sua conta. Verifique journalctl --list-boots, a configuração de armazenamento e os avisos de permissão. Não conclua que a rotação apagou os registros: arquivos rotacionados ainda disponíveis podem ser consultados.