Ler registos com o journalctl

Módulo 6: Serviços e registos · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Depois desta lição, saberá pesquisar de forma dirigida os registos do seu servidor com o journalctl (por serviço, prioridade e tempo), saberá onde se encontram outros ficheiros de registo e evitará que os registos encham o seu disco.

Conceitos-chave: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioridade (err, warning, info), armazenamento persistente, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

O registo como primeira testemunha

Quando algo não funciona no seu servidor, a razão está quase sempre num registo. Um site que mostra uma página de erro, um serviço que não arranca, uma cópia de segurança que não correu esta noite: o servidor anotou tudo. Um bom administrador consulta primeiro o registo e só depois começa a alterar coisas.

Nos servidores Linux modernos, o journald (parte do systemd) reúne as mensagens do kernel, do próprio systemd e de todos os serviços num único registo: o journal. Lê-se com o journalctl.

Para poder ler tudo, tem de pertencer ao grupo adm ou systemd-journal, ou utilizar sudo. Sem essas permissões, vê apenas as suas próprias mensagens.

Onde fica guardado? Persistente ou volátil

O journald guarda o journal num de dois locais:

• em /var/log/journal/: persistente, os registos mantêm-se após um reinício;
• em /run/log/journal/: volátil, em memória, desaparecem após um reinício.

A definição predefinida (Storage=auto em /etc/systemd/journald.conf) escolhe o modo persistente se a pasta /var/log/journal/ existir. No Debian, o pacote systemd cria essa pasta desde o Debian 11, e no Ubuntu ela também existe. Verifique:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Se vir apenas um arranque, embora o servidor já tenha sido reiniciado, os seus registos são voláteis. Crie a pasta (sudo mkdir -p /var/log/journal e sudo systemd-tmpfiles --create --prefix /var/log/journal) e reinicie o journald. Isto é importante: depois de uma falha, quer precisamente saber o que aconteceu antes do reinício.

Desde o Debian 12, o Debian já não instala o rsyslog por predefinição. Esse programa escrevia antigamente ficheiros de texto como /var/log/syslog e /var/log/auth.log. Num servidor Debian novo, esses ficheiros não existem; tudo está no journal. O Ubuntu ainda tem o rsyslog. Os guias que dizem "consulte /var/log/auth.log" podem ser traduzidos, no Debian, para journalctl -u ssh.

Pesquisar: os filtros que realmente vai usar

Sem filtro, o journalctl mostra tudo, a começar pelo mais antigo. Raramente é isso que pretende. Os filtros mais importantes, que pode combinar:

As prioridades vão de 0 (emerg) a 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Com -p err obtém err e tudo o que for mais grave. -p warning mostra também os avisos.

Um percurso de pesquisa típico. O seu site dá um erro 502 desde esta manhã:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

A causa está lá escrita: um erro de escrita na linha 42 de um ficheiro de configuração. O estado 78 (CONFIG) confirma que se trata de um erro de configuração. Não precisa de adivinhar nada.

Duas dicas para a leitura:

• Leia de cima para baixo e procure o primeiro erro. Um erro provoca muitas vezes toda uma série de mensagens subsequentes. O primeiro é normalmente a causa.
• Repare na hora. O que mudou por volta desse momento? Uma atualização automática (lição 4.2: /var/log/unattended-upgrades/), uma alteração feita por si, um reinício?

Outros ficheiros de registo

Nem tudo está no journal. Muitos programas escrevem também (ou apenas) ficheiros próprios em /var/log/:

Os ficheiros de texto grandes leem-se com less (pesquisar com /), o fim com tail -n 50, em direto com tail -f, e filtram-se com grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Os registos dos contentores Docker não estão em /var/log, mas no próprio Docker: docker compose logs (lição 9.3).

Os registos não devem encher o disco

Um disco cheio é uma das causas mais frequentes de um servidor que "de repente" deixa de funcionar: as bases de dados param, as atualizações falham e, por vezes, nem sequer consegue iniciar sessão. Os registos são muitas vezes os culpados.

O journal limita-se a si próprio. Por predefinição, utiliza no máximo 10% do sistema de ficheiros, com um máximo de 4 GB (SystemMaxUse=). Quanto utiliza neste momento e como fazer limpeza:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # remover com mais de 30 dias
anna@web1:~$ sudo journalctl --vacuum-size=500M    # até 500 MB

Se pretender um limite fixo, coloque num ficheiro drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

e reinicie o journald com sudo systemctl restart systemd-journald.

Os ficheiros de texto em /var/log são geridos pelo logrotate: todos os dias ou todas as semanas, um ficheiro é renomeado (error.log.1), as versões mais antigas são comprimidas (.gz) e as mais antigas de todas são eliminadas. As regras por programa estão em /etc/logrotate.d/. Os pacotes da distribuição trazem a sua própria regra. Se um programa ou script seu escrever num ficheiro de registo próprio, crie uma regra; caso contrário, o ficheiro cresce indefinidamente.

Descobrir o que ocupa espaço:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Registos e privacidade

Os registos contêm endereços IP, nomes de utilizador e, por vezes, endereços de e-mail: são dados pessoais. Não os guarde mais tempo do que o necessário (algumas semanas a alguns meses é habitual para um servidor pequeno), não os deixe acessíveis publicamente (uma pasta /logs na raiz do seu site é um erro conhecido) e não os copie levianamente para serviços de terceiros.

No AlmaLinux e no Rocky Linux

O journalctl funciona da mesma forma. Aí, o rsyslog continua ativo por predefinição, com ficheiros como /var/log/messages e /var/log/secure (o equivalente de auth.log). As mensagens do SELinux estão em /var/log/audit/audit.log; ausearch -m avc -ts recent mostra as recusas recentes.

Resumo

• O journald reúne todas as mensagens no journal; leia-o com journalctl, filtrando por serviço (-u), prioridade (-p), tempo (--since) e arranque (-b).
• Verifique se o journal é persistente (/var/log/journal existe); caso contrário, perde os seus registos após um reinício.
• O Debian 12 e versões posteriores não têm rsyslog por predefinição e, portanto, não têm /var/log/auth.log nem /var/log/syslog; tudo está no journal.
• Procure o primeiro erro e veja o que mudou por volta desse momento.
• Vigie o tamanho: o journal limita-se a si próprio (--disk-usage, --vacuum-*), os ficheiros de texto são geridos pelo logrotate.

Questionário

Exercício

Exercício Z6.2: Analisar um serviço que falha. O ficheiro de exemplo journal-crash-1.txt contém o resultado de systemctl status e journalctl de um serviço que reinicia repetidamente e depois desiste. Responda: como se chama o serviço, quantas vezes o systemd tentou arrancá-lo, com que código de saída parou, qual é a causa segundo a primeira mensagem de erro e a que horas o systemd desistiu? O programa compara com a chave fixa. Depois, verifique no seu próprio servidor se journalctl -p err -b mostra erros e se o seu journal é persistente.

Para saber mais

• Manual journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Manual journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, notas de lançamento 5.1.7 (rsyslog deixa de ser instalado por predefinição): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html