Como corrigir um diário completo do systemd

11 min de leitura - 20 de maio de 2026

hero section cover
Índice
  • Como resolver um problema de journal do systemd cheio
  • Diagnosticar o problema
  • Limpar registos com segurança
  • Configurar os limites de tamanho do Journald
  • Automatização da manutenção de registos
  • Conclusão
Partilhar

Diagnosticar e corrigir um diário systemd completo com comandos de vácuo, limites de tamanho journald.conf, temporizadores de limpeza automatizados e encaminhamento de registos.

Como resolver um problema de journal do systemd cheio

O journal do systemd armazena todas as mensagens de registo que o seu servidor produz e, num VPS com uma partição raiz pequena, pode consumir silenciosamente todo o seu espaço em disco disponível. Quando isso acontece, os serviços não conseguem iniciar, as gravações ficam paralisadas e perde-se exatamente o diagnóstico de que precisa para descobrir o que correu mal. Este guia aborda como diagnosticar o problema, libertar espaço imediatamente e configurar o journald para que isso não volte a acontecer.


 

Diagnosticar o problema

Comece por verificar quanto espaço o diário está a utilizar:

journalctl --disk-usage

Isto indica o tamanho combinado de todos os ficheiros de registo ativos e arquivados. Compare esse valor com o espaço disponível no disco df -h. Numa partição raiz de 20 GB, mesmo 2 GB de registos representam mais de 10% do disco total, o que é suficiente para causar problemas.

Em seguida, descubra quais os serviços que estão a gerar mais ruído. Esta linha de comando classifica as 10 principais fontes de registos das últimas 24 horas:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Filtre especificamente por erros com journalctl -p err -b para ver se um único serviço está preso num ciclo de falhas e a sobrecarregar o journal. Também pode verificar se o journald está a limitar a taxa de qualquer serviço:

journalctl -u systemd-journald | grep -i "suppressed"

Mensagens de supressão significam que um serviço excedeu o limite padrão de 10.000 entradas em 30 segundos. Esse é o seu culpado.

Algumas coisas são especialmente comuns em instâncias VPS. Se Storage=auto estiver definido e /var/log/journal/ existir, o journald utiliza armazenamento persistente com um limite padrão de aproximadamente 4 GB. Numa partição raiz pequena, isso enche-se rapidamente. Desligamentos não corretos também podem deixar ficheiros de diário corrompidos com um .journal~ . Esses ficheiros não são substituídos normalmente e continuam a ocupar espaço.

Limpar registos com segurança

Antes de remover qualquer coisa, rode o ficheiro de registo ativo para que os registos atuais sejam preservados:

journalctl --rotate

Em seguida, elimine os registos arquivados. Pode filtrar por idade, tamanho ou número de ficheiros:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

A primeira opção elimina registos com mais de 24 horas. A segunda reduz o tamanho total do diário para 100 MB. A terceira mantém apenas os cinco ficheiros arquivados mais recentes. Escolha a opção que melhor se adequar à sua situação.

Se o disco estiver completamente cheio e os comandos journalctl não responderem, poderá ser necessário eliminar os ficheiros de registo manualmente:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Este é um último recurso. Apaga todos os registos armazenados e recria o diretório com as permissões corretas. Após qualquer limpeza, reinicie o daemon e verifique:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Configurar os limites de tamanho do Journald

As definições padrão do journald são generosas. Num VPS, são demasiado generosas. Edite a configuração para definir limites rígidos para o armazenamento de registos. Crie um ficheiro de substituição em vez de editar diretamente a configuração principal, para que as suas alterações sejam mantidas após atualizações de pacotes:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

As diretivas principais:

ParâmetroVPS (disco de 20-40 GB)Servidor dedicadoO que faz
SystemMaxUse500M a 1G2 G a 5 GLimite máximo para o tamanho total do diário
SystemKeepFree1 GB10% do discoEspaço livre reservado para o SO
MaxRetentionSec7 a 14 dias30 a 90 diasElimina automaticamente os registos mais antigos do que este
SystemMaxFileSize20 MB a 50 MB100MTamanho máximo por ficheiro de registo

Definir ambos SystemMaxUse e SystemKeepFree proporciona uma abordagem dupla: os registos são limitados a um tamanho fixo e o sistema tem sempre margem de manobra, independentemente do que mais estiver no disco.

Armazenamento persistente vs. volátil

A Storage= controla para onde vão os registos. Defina Storage=persistent para gravar os registos /var/log/journal/ no disco. É isso que se pretende para servidores de produção, porque os registos sobrevivem às reinicializações e é possível investigar falhas após o facto. Se o diretório não existir, crie-o:

sudo mkdir -p /var/log/journal

A alternativa, Storage=volatile, mantém os registos na RAM em /run/log/journal/. Os registos desaparecem ao reiniciar. Isto faz sentido para contentores efémeros ou servidores que reencaminham todos os registos para um sistema externo.

Desativar a compressão em servidores de alto tráfego

O Journald comprime objetos de dados maiores que 512 bytes por padrão. Em servidores que lidam com grande volume de logs, isso aumenta a sobrecarga da CPU. Defina Compress=no se estiver a reencaminhar registos externamente e não precisar de minimizar o armazenamento local. Defina também ForwardToConsole=no em produção. O encaminhamento da consola é síncrono, e uma consola serial virtual bloqueada pode bloquear completamente o daemon journald.

Após qualquer alteração de configuração, reinicie o serviço:

sudo systemctl restart systemd-journald

Automatização da manutenção de registos

A limpeza manual não é escalável. Crie um temporizador systemd para limpar os registos de forma programada. Configure uma unidade de serviço em /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Em seguida, crie um temporizador correspondente em /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Ative-o com sudo systemctl enable --now journal-vacuum.timer. O temporizador é executado todos os domingos às 2h e aplica retenção baseada no tempo e no tamanho numa única passagem.

Uma coisa que o temporizador não detecta: ficheiros de registo corrompidos. Após um encerramento não correto, o journald coloca os ficheiros danificados em quarentena, acrescentando um ~ ao nome do ficheiro. Estes .journal~ arquivos ainda contam para o uso do disco, mas não serão limpos automaticamente. Verifique e remova os antigos periodicamente:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Reencaminhamento de registos para o exterior

Para servidores onde é necessária retenção a longo prazo sem aumentar o armazenamento local, encaminhe os registos para um sistema centralizado. A abordagem mais simples é ativar o encaminhamento de syslog em journald.conf:

ForwardToSyslog=yes

Para registos estruturados com metadados completos (PID, UID, nomes de unidades), utilize systemd-journal-remote para enviar entradas no formato JSON para uma plataforma de gestão de registos. O armazenamento externo de registos também protege a sua pista de auditoria caso o disco local falhe ou o servidor seja comprometido.

Conclusão

Um journal do systemd cheio é fácil de corrigir e de prevenir. Os passos principais:

  • Verifique a utilização com journalctl --disk-usage e identifique serviços ruidosos.
  • Liberte espaço imediatamente com journalctl --rotate seguido de --vacuum-size ou --vacuum-time.
  • Defina limites de tamanho explícitos num ficheiro de substituição do journald.conf.
  • Automatize a limpeza com um temporizador do systemd.
  • Encaminhe os registos externamente para retenção a longo prazo.

Os planos de VPS e servidores dedicados da FDC fornecem a E/S de disco e o armazenamento necessários para cargas de trabalho de registos de produção.

Blogue

Em destaque esta semana

Mais artigos
Processos Zombie em Linux: Localizar, Remover, Prevenir

Processos Zombie em Linux: Localizar, Remover, Prevenir

Saiba como identificar, remover e evitar processos zombie no Linux. Comandos, correcções de código e dicas de monitorização para administradores de servidores.

15 min de leitura - 19 de maio de 2026

Lista de verificação de endurecimento do servidor Linux

15 min de leitura - 8 de maio de 2026

Mais artigos