journalctl: cheat sheet para ver e filtrar logs do Linux

journalctl em uma linha: journalctl -u <service> -f segue o log de um serviço ao vivo, journalctl -u <service> -n 100 mostra as últimas 100 linhas, e journalctl --since "1 hour ago" mostra tudo que é recente. Isso cobre 90% dos momentos “por que esse serviço caiu”. O resto deste cheat sheet são os padrões prontos para colar que te poupam de reler o man page às 2h da manhã — filtrar por unidade, por tempo, por prioridade e por boot, mais os comandos de limpeza que impedem o journal de comer o seu disco. Todo comando abaixo roda como está em qualquer distro com systemd (Ubuntu, Debian, Fedora, Arch).

O que é o journalctl, e por que não ler o /var/log/syslog direto?

O logging à moda antiga gravava arquivos de texto em /var/log — syslog, auth.log, messages. O systemd substituiu isso pelo journal: um log binário e indexado, gerenciado pelo systemd-journald. Um grep comum não consegue lê-lo; o journalctl é a única porta de entrada, e em troca você filtra por serviço, tempo, boot e severidade sem malabarismo de regex.

O modelo mental é simples: o journal guarda tudo, e o journalctl é a ferramenta de consulta. Um serviço não precisa de arquivo de log próprio — tudo que ele escreve no stdout/stderr enquanto roda sob systemd cai no journal automaticamente. Por isso o journalctl -u nginx funciona mesmo quando você não faz ideia de onde o nginx configurou o log de erros.

Um detalhe: em algumas instalações mínimas o journal é volátil (guardado em /run, apagado no reboot) porque /var/log/journal não existe. Resolva de uma vez:

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

Como ver as últimas 100 linhas de um log?

O -n limita a saída às N linhas mais recentes (o padrão é 10):

journalctl -n 100                      # as últimas 100 linhas de tudo
journalctl -u nginx -n 100             # as últimas 100 linhas de uma unidade
journalctl -n 100 --no-pager           # imprime e sai — perfeito para pipe

O --no-pager importa mais do que parece: sem ele o journalctl abre o less e o seu script, pipe ou one-liner ssh fica travado esperando uma tecla. Todo comando cuja saída vai para um pipe deveria carregá-lo.

Como seguir os logs em tempo real, como o tail -f?

O flag -f é o tail -f do journalctl — ele exibe as entradas novas conforme acontecem:

journalctl -f                    # tudo, ao vivo
journalctl -u sshd -f            # só o daemon SSH, ao vivo
journalctl -u ollama -f -n 50    # ao vivo, mas começando pelas últimas 50 linhas

Esse é o comando para deixar num segundo terminal enquanto você reinicia um serviço no primeiro: systemctl restart nginx num painel, journalctl -u nginx -f no outro, e a causa do crash costuma se entregar em segundos. Eu rodo exatamente esse loop no meu homelab toda vez que um contêiner ou serviço resolve aprontar.

Como ver os logs de um serviço específico?

O -u filtra por unidade systemd:

journalctl -u nginx                    # uma unidade, todo o histórico
journalctl -u nginx -u redis           # várias unidades de uma vez
journalctl _SYSTEMD_UNIT=nginx.service # a alternativa com correspondência exata

Unidades podem criar unidades auxiliares que ficam com a saída interessante — uma aplicação web que falha às vezes loga o erro real em outra unidade. Se o -u <service> não retorna nada mas o serviço claramente roda, descubra o nome real da unidade primeiro:

systemctl list-units --type=service | grep -i <guess>

O mesmo padrão -u funciona para timers (o systemctl list-timers mostra os nomes) e para serviços de usuário — para o que roda sob systemd --user, adicione --user:

journalctl --user -u pipewire -n 50

Como filtrar os logs por data?

--since e --until aceitam timestamps, mas também aceitam frases relativas bem flexíveis:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Junte uma janela de tempo a uma unidade e você tem o tri de incidente em uma linha: “o que a API logou entre 9h e a hora em que ela caiu?” Para uma máquina só, isso é mais rápido que qualquer agregador de logs.

Como mostrar só os erros (ou os warnings)?

O -p filtra por prioridade, usando os nomes de severidade do syslog:

journalctl -p err -b              # só erros, desde este boot
journalctl -p warning..alert -u nginx   # um intervalo de severidades

Prioridades em ordem decrescente: emerg, alert, crit, err, warning, notice, info, debug. Quando uma máquina “está agindo estranho”, o journalctl -p err -b --since today é o teste de sanidade mais rápido — ele responde “alguma coisa está falhando de verdade?” sem o barulho das linhas de info rotineiras.

Como ver os logs do boot anterior?

Serviços que crasham na inicialização produzem linhas de log antes do boot atual, e o journalctl por padrão mostra só o atual. O -b seleciona boots:

journalctl -b                 # só o boot atual
journalctl -b -1              # o boot anterior
journalctl -b -1 -u sshd      # por que o SSH morreu da última vez
journalctl --list-boots       # índice dos boots guardados

Esse é o flag mais útil no cenário “quebrou, reiniciei e agora não vejo mais o erro” — o erro continua lá, um boot para trás.

Referência rápida: os flags que valem a pena decorar

Objetivo	Comando
Seguir um serviço ao vivo	journalctl -u <svc> -f
As últimas 100 linhas	journalctl -n 100
Desde uma hora atrás	journalctl --since "1 hour ago"
Erros deste boot	journalctl -p err -b
Boot anterior	journalctl -b -1
Espaço em disco do journal	journalctl --disk-usage
Saída legível por máquina	journalctl -o json-pretty
Só mensagens do kernel	journalctl -k

Como impedir o journal de encher o disco?

Veja quanto custa e depois imponha um teto:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # manter os 500 MB mais recentes
sudo journalctl --vacuum-time=30d      # manter os 30 dias mais recentes

Para tornar o teto permanente, defina SystemMaxUse=500M na seção [Journal] do /etc/systemd/journald.conf e depois sudo systemctl restart systemd-journald. Com o teto de tamanho e o filtro por boot acima, o journal volta a ser ferramenta e deixa de ser um vazamento de disco lento.

journalctl vs dmesg vs /var/log — onde olhar primeiro?

• journalctl — comportamento de aplicações e serviços. Tudo que o systemd gerencia está aqui, indexado e filtrável. Primeira parada por padrão.
• journalctl -k / dmesg — kernel e hardware: kills de OOM, resets de USB, erros de disco. Se um processo morreu sem explicação, procure o OOM killer aqui antes de culpar a aplicação.
• /var/log/<app>/ — só para aplicações que fazem logging em arquivo próprio (logs de acesso do nginx, PostgreSQL). Mesmo assim, os erros de inicialização costumam cair no journal.

O mesmo fluxo se estende aos serviços de IA locais — quando uma unidade ollama serve trava, o journalctl -u ollama -n 100 mostra a falha de carregamento do modelo na hora, como coberto na comparação entre Ollama e LM Studio.

Esse é o cheat sheet inteiro: -u para unidade, -f para seguir, -n para linhas, --since para tempo, -p para severidade, -b para boots. Seis flags cobrem praticamente toda pergunta de log que uma máquina Linux vai te fazer.