journald: log rotati ma SystemMaxUse resta a 4G

Il sintomo arriva quasi sempre da una metrica o da un allarme disco: /var/log/journal cresce senza fermarsi, anche se i log sembrano “ruotare”.

In un caso tipico, journalctl --disk-usage mostra 4G, ma df -h continua a salire. Il problema non è il log rotator classico. È la retention di systemd-journald, spesso lasciata ai valori di default.

Qui non serve un tutorial generico su systemd. Serve capire perché il limite non si applica, come forzarlo e come verificare che il cambio regga dopo il reboot.

Prerequisiti

• Accesso root o sudo.
• Server Linux con systemd.
• Spazio su /var in crescita o alert su disco.
• Comandi: journalctl, systemctl, mkdir, sed o un editor.

Note: i passaggi sono validi su Debian, Ubuntu, AlmaLinux e derivate con systemd recente.

Step 1: conferma il sintomo con due misure diverse

Prima misura il disco reale. Poi misura i file del journal. Se i numeri non tornano, il problema è quasi sempre la retention o la compressione.

Usa questi comandi:

df -h /var
journalctl --disk-usage
ls -lh /var/log/journal/*

# Output: /var quasi pieno; journalctl --disk-usage mostra un valore alto o stabile; i file sotto /var/log/journal sono numerosi e grandi.

Se il journal occupa molto, ma non cambia dopo la rotazione, significa che il limite non è stato impostato in modo coerente. In alcuni casi il file journald.conf è rimasto commentato. In altri, la config è stata messa nel posto giusto ma con sintassi sbagliata.

Step 2: controlla la configurazione effettiva di journald

Non fidarti del file che hai modificato. Verifica il valore letto dal demone. È il passaggio che evita ore perse su un override ignorato.

Apri la configurazione principale:

systemd-analyze cat-config systemd/journald.conf | sed -n '1,220p'

# Output: vedi il file base, eventuali drop-in e i parametri realmente attivi.

Cerca in particolare SystemMaxUse, SystemKeepFree, RuntimeMaxUse e MaxRetentionSec. Se mancano, journald usa i default dinamici, che spesso non bastano in produzione.

Se vuoi una vista rapida:

grep -R --line-number -E '^(SystemMaxUse|SystemKeepFree|RuntimeMaxUse|MaxRetentionSec)=' /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null

# Output: una o più righe con i parametri attivi, oppure nessun risultato.

Warning: se il file è dentro /etc/systemd/journald.conf.d/, il nome deve finire con .conf. Un file senza estensione viene ignorato.

Step 3: imposta un limite esplicito e realistico

Il punto non è “tenere pochi log”. Il punto è evitare che il journal rubi spazio a database, cache o code. In molte macchine bastano 300M o 500M. Su nodi grandi, il limite va dimensionato sul volume del traffico e sul tempo di retention richiesto.

Se preferisci fare da interfaccia, qui non c’è un pannello grafico standard. Questa parte è solo da riga di comando.

Modifica il file:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/10-retention.conf > /dev/null <<'EOF'
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
RuntimeMaxUse=100M
MaxRetentionSec=7day
EOF

# Output: il file di override viene creato senza errori.

Perché questi parametri:

• SystemMaxUse limita lo spazio su disco persistente.
• SystemKeepFree lascia margine libero per il sistema.
• RuntimeMaxUse protegge il journal in memoria o su storage volatile.
• MaxRetentionSec taglia i log troppo vecchi anche se il disco è ancora capiente.

Se il server è piccolo, SystemKeepFree è spesso più importante di SystemMaxUse. Impedisce che journald usi l’ultimo spazio utile quando arrivano picchi di log.

Step 4: ricarica journald e forza la pulizia

Dopo la modifica non basta attendere. Serve ricaricare il demone e, in molti casi, chiedere una pulizia esplicita.

sudo systemctl restart systemd-journald
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=7d

# Output: journald riparte, i file vecchi vengono rimossi e lo spazio sotto /var/log/journal scende.

Se il servizio è molto attivo, la pulizia può lasciare qualche MB in più del previsto. È normale. L’obiettivo è rientrare nel limite, non azzerare tutto.

Per controllare subito il risultato:

journalctl --disk-usage
systemctl status systemd-journald --no-pager

# Output: il consumo scende verso il valore impostato e il servizio resta active (running).

Step 5: verifica che il limite sopravviva al reboot

Molti fix funzionano fino al riavvio. Poi il server torna a crescere perché il file era in un percorso sbagliato o il formato era errato.

Fai una verifica dopo il reboot o, se il reboot non è possibile, controlla il caricamento effettivo dei drop-in. Il punto è confermare che il parametro non sia solo “presente”, ma letto.

systemd-analyze cat-config systemd/journald.conf | grep -E '^(SystemMaxUse|SystemKeepFree|RuntimeMaxUse|MaxRetentionSec)='
journalctl --disk-usage

# Output: i parametri compaiono con i valori attesi e il consumo rimane sotto controllo.

Se vuoi essere più rigoroso, crea un piccolo test di carico log. Basta un ciclo breve, poi un nuovo controllo del disco:

for i in $(seq 1 2000); do logger -p user.info "test journald retention $i"; done
sleep 2
journalctl --disk-usage

# Output: il consumo cresce poco o si stabilizza dopo la pulizia automatica.

Note: questo test usa logger, disponibile quasi ovunque. Non genera file applicativi, ma simula bene un flusso di eventi di sistema.

Verifica finale

La verifica finale non è solo “lo spazio è sceso”. Deve dimostrare che il comportamento è stabile.

• df -h /var mostra margine libero sufficiente.
• journalctl --disk-usage resta entro il limite scelto.
• systemd-analyze cat-config mostra il drop-in corretto.
• systemctl status systemd-journald non segnala errori di parsing.

Se hai un monitoraggio, aggiungi una soglia su /var/log/journal o sul filesystem che lo contiene. È più utile dell’allarme generico sul disco, perché ti avvisa prima che il volume entri in sofferenza.

Una buona soglia pratica è: alert al 75%, warning al 60% del limite assegnato a journald. Così non aspetti il picco per intervenire.

Troubleshooting

1) Failed to parse configuration file: Invalid argument

Causa: sintassi errata nel file journald.conf, spesso per unità sbagliate o spazi nel punto sbagliato.

Fix: valida il file e riavvia.

sudo systemd-analyze verify /etc/systemd/journald.conf.d/10-retention.conf
sudo systemctl restart systemd-journald

# Output: nessun errore di parsing e servizio riavviato.

2) Directory /var/log/journal does not exist

Causa: journald sta salvando solo in runtime, oppure la directory persistente non è stata creata.

Fix: crea la directory e forza la persistenza.

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

# Output: il journal torna persistente su disco.

3) Vacuuming done, freed 0B of archived journals

Causa: i log sono già sotto soglia, oppure il limite non è quello atteso e journald non ha nulla da rimuovere.

Fix: verifica il valore effettivo e il percorso del drop-in.

systemd-analyze cat-config systemd/journald.conf | less
journalctl --disk-usage

# Output: trovi il parametro applicato e capisci se il vacuum non aveva materiale da eliminare.

Conclusione

Il punto debole di journald non è quasi mai il demone. È la fiducia nei default, che in produzione diventano costosi in fretta.

Un limite esplicito, un drop-in corretto e una verifica dopo il reboot risolvono il problema in modo pulito. Come prossimo passo, aggiungi un check automatico su journalctl --disk-usage nel tuo monitoraggio, così il sintomo non torna in silenzio.