Comando journalctl: domine os registos do systemd

Um servidor Linux moderno regista tudo num único sítio: falhas de autenticação, serviços que caem, tarefas do cron, mensagens do kernel. Esse sítio é o journal do systemd, e a porta de entrada chama-se journalctl. Quem administra sistemas usa-o para perceber porque é que um serviço não arranca; quem trabalha em cibersegurança usa-o para reconstruir a cronologia de um ataque, minuto a minuto, sem saltar entre dez ficheiros de log diferentes.

Neste artigo percorremos os filtros que realmente interessam — por unidade, por prioridade, por janela temporal, por arranque — e mostramos como o journalctl se usa em cenários reais de resposta a incidentes. No fim, pode praticar tudo num simulador interativo sem sair da página.

O que faz o journalctl

O journalctl consulta o journal: a base de dados de registos mantida pelo systemd-journald. Ao contrário dos ficheiros de texto clássicos em /var/log, o journal é estruturado — cada registo guarda dezenas de campos (unidade, PID, UID, executável, prioridade, carimbo temporal com precisão de microssegundos) — e é indexado, o que permite filtrar milhões de registos em segundos. Todos os serviços geridos pelo systemd, o kernel e as aplicações que falam syslog escrevem no mesmo journal, pela mesma ordem cronológica.

A forma geral combina filtros de seleção, uma janela temporal e um formato de saída:

journalctl [-u UNIDADE] [-p NÍVEL] [--since …] [--until …] [-b [N]] [-o FORMATO]

Um pormenor importante: sem opções, o journalctl mostra o journal inteiro, do registo mais antigo para o mais recente, de todos os arranques guardados. Numa máquina com semanas de atividade, isso são centenas de milhares de linhas — a arte está em filtrar.

As opções que interessam

Filtrar por unidade e por prioridade

• -u UNIDADE — mostra só os registos de uma unidade do systemd (por exemplo -u sshd ou -u nginx), incluindo as mensagens que o próprio systemd escreve sobre ela: arranques, falhas, contadores de reinício.
• -p NÍVEL — filtra pela prioridade herdada do syslog: emerg (0), alert, crit, err, warning, notice, info e debug (7). O filtro é «até este nível»: -p err mostra erros e tudo o que for mais grave.
• -k — apenas mensagens do kernel, o equivalente ao dmesg.
• -g PADRÃO — pesquisa por expressão regular dentro das mensagens: o grep nativo do journal, sem encadear comandos.

# Todos os erros do nginx
journalctl -u nginx -p err

# Todas as tentativas de login falhadas
journalctl -g "Failed password"

Janela temporal e arranques

• --since / --until (abreviados -S / -U) — delimitam o intervalo. Aceitam datas absolutas ("2026-07-28 10:00") e expressões relativas em inglês: today, yesterday, "1 hour ago", "30 min ago".
• -b — restringe ao arranque atual; -b -1 recua ao anterior, -b -2 ao anterior a esse. Com --list-boots vê a lista completa de arranques guardados.
• --utc — apresenta os carimbos em UTC, indispensável quando se correlacionam registos de várias máquinas em fusos diferentes.

Atenção: -b -1 só funciona se o journal for persistente. Em várias distribuições, por omissão, o journal vive em /run/log/journal — memória volátil que se perde no reboot. Para o tornar persistente basta criar o diretório /var/log/journal ou definir Storage=persistent em /etc/systemd/journald.conf.

Saída, tempo real e manutenção

• -n N — as últimas N linhas, como o tail; sem número, assume 10.
• -f — modo follow: mostra as últimas linhas e fica à escuta de registos novos, como o tail -f.
• -r — inverte a ordem, do mais recente para o mais antigo, útil em triagem rápida.
• -o FORMATO — muda o formato de saída: short (omissão), short-iso, cat (só a mensagem) e, sobretudo, json, que expõe cada registo com todos os campos estruturados numa linha — o formato ideal para alimentar um SIEM ou um script de análise.
• -x — acrescenta explicações do catálogo de mensagens, com contexto e sugestões de resolução.
• --disk-usage — mostra quanto espaço o journal ocupa em disco; --vacuum-size=500M e --vacuum-time=30d limpam arquivos antigos por tamanho ou por idade.

# O sshd em tempo real, só a última hora primeiro
journalctl -u sshd --since "1 hour ago" -f

# Um registo em JSON estruturado
journalctl -u sshd -p err -o json -n 1

journalctl em cibersegurança

Deteção de força bruta em tempo real. Um journalctl -u sshd -f mostra as tentativas de autenticação à medida que acontecem. Combinado com -g "Failed password" e --since "1 hour ago", responde em segundos às perguntas essenciais: o ataque está a decorrer agora? De que endereços vem? Que contas está a tentar?

Correlação temporal entre serviços. Como todos os registos partilham o mesmo relógio e o mesmo índice, é trivial cruzar eventos: as falhas do sshd às 11:04 e o serviço web a falhar às 11:05 aparecem lado a lado no mesmo comando. Com -b -1 compara-se o comportamento com o arranque anterior — se ontem o serviço arrancava sem erros, o problema nasceu hoje, e a janela de investigação encolhe drasticamente.

Auditoria centralizada e exportação para SIEM. O formato -o json preserva os campos estruturados (_UID, _EXE, _SYSTEMD_UNIT, PRIORITY), que permitem filtrar por utilizador ou por executável sem depender do texto da mensagem — algo que um atacante pode forjar, ao contrário dos campos que o kernel preenche.

Persistência e integridade como controlo defensivo. Um atacante que consiga root tenta apagar o rasto. Journal persistente, reencaminhamento para uma máquina remota e verificação de integridade com journalctl --verify (reforçada com selagem FSS) tornam essa limpeza detetável — a ausência ou corrupção de registos passa a ser, ela própria, um indicador de compromisso.

Experimente no simulador interativo

A simulação abaixo recria o journal de uma máquina fictícia com dois arranques, um ataque de força bruta ao SSH e um serviço web preso num loop de reinício. No painel esquerdo vê o journal completo; no terminal à direita, os registos que sobrevivem aos filtros. Clique nas opções (-u, -p err, --since, -b, -g, -o json, -f…) para compor o seu próprio comando, use Demonstrar tudo para seguir a investigação guiada completa, ou avance passo a passo com Anterior e Seguinte. A nota por baixo dos botões explica cada opção.

Erros comuns e boas práticas

• Confiar num journal volátil: sem /var/log/journal, um reboot apaga tudo — incluindo a evidência de um incidente. Confirme com journalctl --list-boots se existem arranques anteriores.
• Esquecer que -p err é «até err»: o filtro inclui também crit, alert e emerg. Para ver um único nível, use um intervalo como -p warning..warning.
• Escrever as expressões de tempo em português: o --since só entende palavras-chave em inglês (today, "1 hour ago"); com datas absolutas não há ambiguidade.
• Ignorar as mensagens do systemd sobre a unidade: um serviço em loop de reinício conta a história no Scheduled restart job, restart counter is at N — que só aparece com -u UNIDADE, não no log da aplicação.
• Correlacionar máquinas sem --utc: fusos e horas de verão desalinham cronologias; em investigação multi-servidor, normalize sempre para UTC.
• Deixar o journal crescer sem limites: um disco cheio de logs também é uma forma de negação de serviço. Vigie com --disk-usage e defina limites em journald.conf (SystemMaxUse=).
• Analisar como utilizador sem privilégios e concluir que «não há registos»: sem pertencer aos grupos systemd-journal ou adm, só vê o seu próprio journal.

---

Conclusão

O journalctl transforma o caos dos logs num único fluxo pesquisável: -u e -p err para isolar o problema, --since e -b para o situar no tempo, -g para o encontrar, -f para o vigiar em direto e -o json para o entregar ao SIEM. Dominar meia dúzia destas combinações reduz investigações de horas a minutos. Se quer levar estas competências mais longe — da administração de sistemas à resposta a incidentes — conheça o nosso catálogo de serviços de formação e consultoria, e veja também o artigo sobre o useradd, onde a gestão de contas encontra os registos de autenticação que acabou de aprender a filtrar.

Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.