Como corrigir um diário completo do systemd
11 min de leitura - 20 de maio de 2026

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-usageIsto 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 -10Filtre 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 --rotateEm 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=5A 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/journalEste é 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-usageConfigurar 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.confAs diretivas principais:
| Parâmetro | VPS (disco de 20-40 GB) | Servidor dedicado | O que faz |
|---|---|---|---|
| SystemMaxUse | 500M a 1G | 2 G a 5 G | Limite máximo para o tamanho total do diário |
| SystemKeepFree | 1 GB | 10% do disco | Espaço livre reservado para o SO |
| MaxRetentionSec | 7 a 14 dias | 30 a 90 dias | Elimina automaticamente os registos mais antigos do que este |
| SystemMaxFileSize | 20 MB a 50 MB | 100M | Tamanho 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/journalA 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-journaldAutomatizaçã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=500MEm 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.targetAtive-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 -deleteReencaminhamento 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=yesPara 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-usagee identifique serviços ruidosos. - Liberte espaço imediatamente com
journalctl --rotateseguido de--vacuum-sizeou--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.

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