Come risolvere un problema di journal systemd pieno

Il journal di systemd memorizza ogni messaggio di log generato dal server e, su un VPS con una partizione root di piccole dimensioni, può consumare silenziosamente lo spazio disponibile su disco. Quando ciò accade, i servizi non si avviano, le operazioni di scrittura si bloccano e si perdono proprio gli strumenti diagnostici necessari per capire cosa è andato storto. Questa guida spiega come diagnosticare il problema, liberare immediatamente spazio e configurare journald in modo che non si ripeta.

Diagnosi del problema

Inizia controllando quanto spazio sta occupando il journal:

journalctl --disk-usage

Questo dato riporta la dimensione complessiva di tutti i file di journal attivi e archiviati. Confrontalo con lo spazio disponibile sul disco df -h. Su una partizione root da 20 GB, anche 2 GB di log rappresentano oltre il 10% del disco totale, il che è sufficiente a causare problemi.

Successivamente, scopri quali servizi generano più rumore. Questa riga di comando classifica le prime 10 fonti di log delle ultime 24 ore:

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

Filtra specificamente gli errori con journalctl -p err -b per vedere se un singolo servizio è bloccato in un ciclo di crash e sta inondando il journal. Puoi anche verificare se journald sta limitando la frequenza di qualsiasi servizio:

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

I messaggi di soppressione indicano che un servizio ha superato la soglia predefinita di 10.000 voci in 30 secondi. Ecco il colpevole.

Alcune cose sono particolarmente comuni sulle istanze VPS. Se Storage=auto è impostato e /var/log/journal/ esiste, journald utilizza uno spazio di archiviazione persistente con un limite predefinito di circa 4 GB. Su una partizione root di piccole dimensioni, lo spazio si riempie rapidamente. Anche gli spegnimenti non corretti possono lasciare file di journal danneggiati con un .journal~ suffisso. Questi file non vengono ruotati normalmente e continuano a occupare spazio.

Cancellazione sicura dei log

Prima di rimuovere qualsiasi cosa, ruotare il file di registro attivo in modo che i log attuali vengano conservati:

journalctl --rotate

Quindi eliminare i log archiviati. È possibile selezionare i criteri in base a data, dimensione o numero di file:

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

Il primo elimina i log più vecchi di 24 ore. Il secondo riduce la dimensione totale del journal a 100 MB. Il terzo mantiene solo i cinque file archiviati più recenti. Scegli quello più adatto alla tua situazione.

Se il disco è completamente pieno e i comandi journalctl non rispondono, potrebbe essere necessario eliminare manualmente i file di journal:

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

Questa è l'ultima risorsa. Cancella tutti i log memorizzati e ricrea la directory con i permessi corretti. Dopo qualsiasi pulizia, riavvia il demone e verifica:

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

Configurazione dei limiti di dimensione di Journald

Le impostazioni predefinite di journald sono generose. Su un VPS, sono troppo generose. Modifica la configurazione per impostare limiti massimi rigidi per l'archiviazione dei log. Crea un file di override invece di modificare direttamente la configurazione principale, in modo che le tue modifiche rimangano anche dopo gli aggiornamenti dei pacchetti:

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

Le direttive chiave:

Impostazione di entrambi SystemMaxUse e SystemKeepFree ti offre un approccio "cintura e bretelle": i log sono limitati a una dimensione fissa e il sistema ha sempre spazio a disposizione indipendentemente da cos'altro si trovi sul disco.

Archiviazione persistente vs. volatile

La Storage= controlla la destinazione dei log. Impostare Storage=persistent per scrivere i log su /var/log/journal/ sul disco. Questa è l'impostazione consigliata per i server di produzione, poiché i log sopravvivono ai riavvii e consentono di analizzare i crash a posteriori. Se la directory non esiste, crearla:

sudo mkdir -p /var/log/journal

L'alternativa, Storage=volatileconserva i log nella RAM /run/log/journal/. I log scompaiono al riavvio. Questa opzione è indicata per i container effimeri o per i server che inoltrano tutti i log a un sistema esterno.

Disabilitare la compressione su server ad alto traffico

Journald comprime per impostazione predefinita gli oggetti dati più grandi di 512 byte. Su server che gestiscono un elevato throughput di log, ciò aggiunge un sovraccarico della CPU. Impostare Compress=no se si inoltrano i log esternamente e non è necessario ridurre al minimo lo spazio di archiviazione locale. Impostare ForwardToConsole=no in produzione. L'inoltro della console è sincrono e una console seriale virtuale bloccata può bloccare completamente il demone journald.

Dopo qualsiasi modifica alla configurazione, riavviare il servizio:

sudo systemctl restart systemd-journald

Automatizzazione della manutenzione dei log

La pulizia manuale non è scalabile. Crea un timer systemd per ripulire i log a intervalli regolari. Configura un'unità di servizio in /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

Quindi creare un timer corrispondente in /etc/systemd/system/journal-vacuum.timer:

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

Abilitalo con sudo systemctl enable --now journal-vacuum.timer. Il timer si avvia ogni domenica alle 2 del mattino e applica la conservazione basata sia sul tempo che sulle dimensioni in un unico passaggio.

Una cosa che il timer non rileva: i file di journal danneggiati. Dopo uno spegnimento non corretto, journald mette in quarantena i file danneggiati aggiungendo un ~ al nome del file. Questi .journal~ file continuano a incidere sull'utilizzo del disco, ma non verranno ripuliti automaticamente. Controlla periodicamente e rimuovi quelli vecchi:

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

Inoltro dei log all'esterno

Per i server in cui è necessaria una conservazione a lungo termine senza aumentare lo spazio di archiviazione locale, inoltrare i log a un sistema centralizzato. L'approccio più semplice consiste nell'abilitare l'inoltro syslog in journald.conf:

ForwardToSyslog=yes

Per i log strutturati con metadati completi (PID, UID, nomi delle unità), usa systemd-journal-remote per inviare le voci in formato JSON a una piattaforma di gestione dei log. L'archiviazione esterna dei log protegge inoltre la traccia di audit in caso di guasto del disco locale o di compromissione del server.

Conclusione

Un journal systemd pieno è semplice da risolvere e facile da prevenire. I passaggi chiave:

• Verificare l'utilizzo con journalctl --disk-usage e identificare i servizi che generano rumore.
• Liberare immediatamente spazio con journalctl --rotate seguito da --vacuum-size oppure --vacuum-time.
• Imposta limiti di dimensione espliciti in un file di override di journald.conf.
• Automatizzare la pulizia con un timer systemd.
• Inoltra i log esternamente per la conservazione a lungo termine.

I piani VPS e server dedicati di FDC forniscono l'I/O del disco e lo spazio di archiviazione necessari per i carichi di lavoro dei log di produzione.