Con il journal persistente di default systemd 259 ti riempie il disco

TL;DR

Cosa è cambiato davvero con systemd 259?

Passo 1: capire in che regime sei, e quanto stai consumando

Passo 2: mettere un tetto con tre righe

Passo 3: pulire l'arretrato, subito e senza riavvii

Passo 4: scegliere il regime giusto per ogni classe di macchina

Il 17 dicembre 2025 è uscito systemd 259, e in mezzo alle novità di cui si è parlato molto, la deprecazione formale degli script SysV, il NAT solo via nftables, c'è un cambio di default di cui si è parlato pochissimo e che è l'unico dei tre a mangiare spazio disco: lo storage del journal è ora persistent di default. Fino alla versione 258 il default era auto, un compromesso silenzioso: se la directory /var/log/journal esisteva, i log finivano su disco; se non esisteva, vivevano in RAM sotto /run/log/journal e sparivano a ogni riavvio. Da systemd 259 la directory viene creata automaticamente e i log vanno su disco, punto. Con i limiti di fabbrica di journald, che si prende fino al 10% del filesystem con un tetto di 4 GB, su un VPS con 40 GB di disco significa che il sistema di logging può occupare da solo lo spazio di un piccolo database, senza che tu abbia deciso niente. In questo articolo faccio il giro completo in cinque passi: capire in che regime è la tua macchina, misurare quanto sta consumando davvero, mettere limiti sensati con un drop-in di tre righe, pulire l'arretrato, e scegliere consapevolmente il regime giusto per ogni classe di macchina, perché il journal persistente è un'ottima cosa esattamente finché è una scelta.

Cosa è cambiato: da systemd 259 (17 dicembre 2025) Storage= di journald ha default persistent: /var/log/journal viene creata automaticamente e i log vanno su disco anche dove prima erano volatili.
Misura: journalctl --disk-usage dice quanto stai consumando; il tetto di fabbrica è 10% del filesystem, massimo 4 GB.
Limita: drop-in in /etc/systemd/journald.conf.d/ con SystemMaxUse=500M e MaxRetentionSec=1month, poi riavvio di systemd-journald.
Pulisci l'arretrato: journalctl --vacuum-size=500M --vacuum-time=30d.
Se vuoi il vecchio comportamento volatile (container, SD card, edge): Storage=volatile nello stesso drop-in.
Occhio al doppione: se sulla macchina gira anche rsyslog, gli stessi log sono scritti due volte, journal più file di testo.

La release ufficiale di systemd v259 lo mette nero su bianco nel NEWS file: il default dello storage del journal è ora persistent, mentre prima era auto e la presenza o assenza di /var/log/journal determinava il comportamento effettivo. Il demone adesso crea la directory se manca e scrive lì, incondizionatamente; la modalità volatile resta disponibile, ma va chiesta esplicitamente. Il cambio si estende anche ai journal namespace, gli spazi di log separati introdotti nelle versioni recenti per isolare i log di servizi specifici: anche loro, persistenti di default.

Prima domanda pratica: ti riguarda? Dipende da cosa esegue la tua macchina. Debian 13 trixie è ferma a systemd 257 e ci resterà per il suo ciclo di vita: lì il default nuovo arriverà solo con la prossima release. Ti riguarda subito se stai su distribuzioni rolling, su immagini cloud che seguono l'upstream da vicino, o sulle prossime release di ogni famiglia, che erediteranno systemd 259 o successivi. Ma, ed è il punto che rende questo pezzo utile anche a chi è su trixie, il problema dello spazio non nasce con la 259: nasce ovunque il journal sia persistente senza limiti pensati, e su Debian la directory /var/log/journal esiste di default da anni. La 259 non inventa il problema: lo estende alle macchine che finora ne erano immuni per caso, tipicamente le immagini minimali dove nessuno aveva mai creato quella directory. Il censimento che segue vale per tutte.

Già che hai il NEWS file davanti, le altre due voci della 259 che un sysadmin deve mettere a calendario sono di segno diverso ma della stessa famiglia, default e compatibilità che cambiano. La prima: il supporto agli script di init System V è formalmente deprecato, con rimozione annunciata per systemd 260; se nel tuo parco sopravvive qualche demone legacy avviato da uno script in /etc/init.d senza unit nativa, il tempo per scrivergli una unit è adesso, non quando la rimozione arriverà nelle distribuzioni. La seconda: systemd-networkd e systemd-nspawn non creano più regole NAT via iptables, solo nftables; chi ha container nspawn su macchine ancora agganciate a iptables-legacy ha un motivo in più per completare una migrazione che era comunque dovuta.

Tre comandi, nessuna ambiguità:

journalctl --disk-usage
# Archived and active journals take up 3.8G in the file system.

systemd-analyze cat-config systemd/journald.conf | grep -E '^(Storage|SystemMaxUse|MaxRetentionSec)'
# mostra la configurazione EFFETTIVA, drop-in compresi

ls -d /var/log/journal 2>/dev/null && echo "persistente" || echo "volatile (o auto senza directory)"

Il primo numero è quello che conta: se è nell'ordine dei gigabyte su una macchina che non ha mai avuto una policy sui log, hai trovato spazio gratis da riprenderti. Il secondo comando merita una nota di metodo: la configurazione di journald può vivere nel file principale, nei drop-in sotto /etc/systemd/journald.conf.d/ e nei default compilati, e systemd-analyze cat-config è l'unico modo onesto di sapere cosa vale davvero, invece di dedurlo leggendo un file che magari è interamente commentato. I default di fabbrica, documentati nella manpage di journald.conf, sono pensati per non riempire mai il disco da soli: SystemMaxUse vale il 10% del filesystem con un tetto di 4 GB, e journald smette di crescere anche quando lo spazio libero scende sotto la soglia di SystemKeepFree. Ma "non riempire il disco" e "usare lo spazio in modo sensato" sono obiettivi diversi: su un VPS da 40 GB con un carico web tipico, 4 GB di log binari sono quasi sempre sproporzionati rispetto al loro valore.

Nel mio lavoro sui VPS delle PMI questo è un classico del censimento iniziale: macchine dove nessuno ha mai deciso una retention, e dove i gigabyte del journal convivono con un disco all'85% che genera ansia a ogni deploy. Nel mio profilo professionale trovi come imposto la gestione di questi parchi macchine, dove la regola è che ogni consumo di risorse deve corrispondere a una decisione, non a un default.

La configurazione si fa con un drop-in, mai modificando il file principale, così gli aggiornamenti di sistema non ti chiederanno mai di riconciliare le modifiche:

mkdir -p /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/50-limits.conf <<'EOF'
[Journal]
SystemMaxUse=500M
MaxRetentionSec=1month
EOF
systemctl restart systemd-journald

I due parametri lavorano insieme e coprono assi diversi: SystemMaxUse è il tetto di spazio, MaxRetentionSec è il tetto di età, e journald rispetta il più restrittivo dei due. Esistono anche i gemelli per il regime volatile, RuntimeMaxUse e compagnia, che governano quanto il journal può occupare in RAM sotto /run: su macchine con poca memoria vale la pena dar loro un valore esplicito, perché anche la RAM è un disco che si riempie. E per i servizi logorroici c'è una leva complementare che agisce alla sorgente invece che sul contenitore: il rate limiting di journald (RateLimitIntervalSec e RateLimitBurst), che taglia le raffiche di messaggi identici prima che diventino gigabyte; il suo uso va però dichiarato al team, perché i messaggi soppressi sono anche diagnostica che non vedrai. Per un VPS web tipico, 500 MB e un mese sono un punto di partenza generoso: abbastanza storia per la diagnosi di un incidente scoperto in ritardo, abbastanza poco da non pesare. Le macchine con requisiti di conformità hanno esigenze diverse, e in quel caso la retention lunga va progettata, non subita: log spediti fuori macchina o su una partizione dedicata, non accumulati sul disco di sistema fino al tetto di fabbrica. La regola che applico è di igiene decisionale più che tecnica:

La retention dei log è una decisione di business travestita da parametro tecnico: quanto indietro devi poter guardare, e chi lo pretende? Se la risposta non esiste, il numero giusto è piccolo. Se la risposta esiste, il posto giusto per i log quasi mai è il disco di sistema del server che li produce.

Il drop-in governa il futuro; l'arretrato si smaltisce con il vacuum, che agisce sui file archiviati del journal e si può lanciare a caldo, senza toccare i servizi:

journalctl --vacuum-size=500M --vacuum-time=30d
journalctl --disk-usage   # verifica del risultato

I due criteri si possono combinare, e il comando riporta esattamente quanti file ha rimosso e quanto spazio ha liberato. Su macchine molto piene la prima esecuzione recupera gigabyte in secondi, ed è uno di quei rari interventi a rischio quasi nullo con beneficio immediato: i file rimossi sono gli archivi più vecchi, il journal attivo non viene toccato. Se in passato la macchina ha vissuto episodi di disco pieno, aggiungi al giro anche journalctl --verify, che controlla l'integrità dei file del journal: le scritture interrotte per mancanza di spazio lasciano a volte archivi corrotti che occupano spazio senza essere leggibili, e il verify li identifica per la rimozione. Se dopo il vacuum --disk-usage resta alto, il colpevole è quasi sempre un servizio particolarmente logorroico, e la classifica si tira fuori in un minuto interrogando il journal stesso, per esempio con journalctl --since yesterday -o json | jq -r '._SYSTEMD_UNIT' | sort | uniq -c | sort -rn | head: prima di comprimere il sintomo conviene sempre chiedersi se un'applicazione che produce centinaia di megabyte di log al giorno non stia cercando di dirti qualcosa.

« Ott 2026 »

Il default nuovo è ragionevole per i server: i log che sopravvivono al riavvio sono esattamente ciò che serve quando una macchina si riavvia da sola alle tre di notte e vuoi sapere perché, ed è il motivo per cui sui VPS di produzione il journal persistente lo attivavo comunque, ben prima che diventasse default. Ci sono però tre classi di macchine dove la scelta opposta è quella giusta, e il punto del cambio di default è che ora la scelta va fatta esplicitamente. I container: il log di un container appartiene alla pipeline di log della piattaforma, non a un journal dentro il filesystem effimero. Le macchine su SD card e storage a scrittura fragile, i Raspberry e l'edge in generale: lì ogni scrittura evitata allunga la vita del supporto, e Storage=volatile con l'eventuale inoltro dei log verso un collettore remoto è la configurazione sana. E gli ambienti usa-e-getta di CI e test, dove la persistenza è solo I/O sprecato. In tutti e tre i casi il drop-in è lo stesso, con Storage=volatile al posto dei limiti, ed è una riga che vale la pena mettere direttamente nelle immagini base, così ogni macchina nasce già nel regime giusto.

Resta l'ultimo controllo, quello che su Debian e derivate vale doppio: la convivenza con rsyslog. Molte installazioni hanno ancora rsyslog accanto a journald, con i log scritti due volte, binari nel journal e testo sotto /var/log, ognuno con la propria retention (quella dei file di testo la governa logrotate, che è un altro capitolo con le sue sorprese). Non è necessariamente un errore, la coppia ha i suoi usi, ma dev'essere una scelta: pagare due volte lo spazio per gli stessi eventi senza saperlo è il tipo di default subìto che questo articolo esiste per eliminare. Il controllo è systemctl is-active rsyslog, e la decisione segue la stessa logica di tutto il resto: un solo sistema di log primario, con limiti scritti, e ogni eccezione motivata per iscritto.

Il quadro finale è questo: systemd 259 ha trasformato in default universale un comportamento che prima dipendeva da un dettaglio del filesystem, e come ogni cambio di default silenzioso premia chi ha l'inventario sotto controllo e sorprende chi non ce l'ha, lo stesso pattern del /tmp diventato tmpfs con Debian 13 e delle novità operative di systemd 257 di cui ho già scritto. La contromisura è sempre la stessa e costa dieci minuti a macchina: misurare, decidere, scrivere la decisione in un drop-in. Se sul tuo parco quei dieci minuti a macchina non li ha mai investiti nessuno, e il sintomo è il solito disco che si riempie senza colpevoli evidenti, la guida ai problemi di spazio disco su VPS è il complemento naturale di questa, e se preferisci che il censimento completo lo faccia qualcuno che lo fa di mestiere, contattami per una consulenza: retention dei log, tmpfs, kernel accumulati e tutte le altre decisioni non prese che stanno occupando il tuo disco si sistemano tipicamente in una mezza giornata di lavoro ordinato.