Soluzione della community

I log di CasaOS riempiono il disco: limita journald in sicurezza

A CasaOS server accumulated more than 5 GB of journal logs, prompting a manual journald size limit and questions about retention and alternate log locations.

In sintesi: limita journald prima che riempia un piccolo disco di sistema CasaOS

Il sistema CasaOS originale aveva più di 5 GB in /var/log/journal. La soluzione duratura non consiste nel cancellare manualmente i file journal. Imposta un limite di dimensione, scegli eventualmente di mantenere una quantità minima di spazio libero e compatta una volta i vecchi log archiviati. Dopodiché, journald applica automaticamente la politica.

Misura il journal prima di modificare qualsiasi cosa

journalctl --disk-usage
du -sh /var/log/journal 2>/dev/null
df -h /var

Se i log consumano diversi gigabyte su un piccolo disco di avvio, decidi quanta cronologia recente ti serve davvero. Per un home server, un limite fisso è solitamente più prevedibile che lasciare che le impostazioni predefinite consumino una percentuale del file system.

Imposta i limiti di dimensione e conservazione in journald.conf

[Journal]
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=14day

SystemMaxUse limita lo spazio di archiviazione dei journal persistenti, mentre SystemKeepFree preserva spazio libero per il resto del sistema operativo. MaxRetentionSec è facoltativo se vuoi anche un limite basato sul tempo. I limiti di dimensione di journald definiscono l'interazione tra questi limiti.

Compatta una volta i vecchi log dopo aver impostato la politica

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G

La compattazione rimuove i file journal archiviati; non sostituisce la configurazione. Se esegui solo la compattazione e non imposti mai un limite, la directory può ricrescere. I comandi di compattazione di journalctl descrivono i comandi di pulizia supportati.

Non arrestare journald solo per sostituire il file di configurazione

Il post del 2024 arrestava il servizio, rimuoveva la configurazione e copiava un file sostitutivo. Funzionava, ma era più invasivo del necessario. Modifica il file in modo sicuro, conserva un backup, quindi riavvia il servizio:

sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo nano /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

Can journald Store Logs on Another Disk?

Non tramite un semplice percorso arbitrario in journald.conf. Storage=persistent destinazioni /var/log/journal; Storage=volatile utilizza /run/log/journal. Se ti serve una conservazione più lunga altrove, inoltra i log a un altro host syslog/journal invece di montare casualmente percorsi di sistema critici.

Trovare il servizio che crea una quantità eccessiva di log

journalctl -p warning..alert --since "24 hours ago"
journalctl --since "24 hours ago" | tail -200
systemctl --failed

Un limite del disco protegge il sistema operativo, ma non risolve il problema di un servizio che registra lo stesso errore migliaia di volte. Risolvi il problema del servizio rumoroso non appena il sistema ha spazio sufficiente.

Se stai valutando il passaggio da un'installazione di CasaOS più datata a un server più simile a un'appliance, la piattaforma ZimaBoard 2 e il backup di ZimaOS offrono un contesto di migrazione più sicuro.

Impedire a un servizio di riempire il journal

Se un container o un demone emette continuamente lo stesso avviso, i limiti globali di archiviazione contengono soltanto i danni. Controlla le unità più rumorose, quindi risolvi la causa:

journalctl --since "1 hour ago" -o short-unix | tail -500
journalctl -u SERVICE_NAME --since "1 hour ago"

Per i servizi gestiti da systemd, i limiti della frequenza dei log per singola unità possono ridurre i picchi senza eliminare tutti gli altri log di sistema. Usa il limite della frequenza solo dopo aver compreso cosa viene soppresso; errori ripetuti di archiviazione, filesystem o rete potrebbero essere proprio gli indizi necessari per risolvere il problema alla radice.

FAQ

Quanto deve essere grande SystemMaxUse?

Non esiste un valore universale. Su un disco di piccole dimensioni dedicato al sistema operativo, da 500 MB a 2 GB è un intervallo pratico da cui iniziare se raramente ti serve una cronologia lunga dei log. Lascia spazio libero sufficiente per gli aggiornamenti e i metadati delle applicazioni.

journalctl --vacuum-size elimina i log correnti?

Rimuove i file journal archiviati finché non si raggiunge la dimensione obiettivo. Esegui prima la rotazione se vuoi spostare il journal attivo nell'insieme dei file archiviati.

Devo usare logrotate per /var/log/journal?

No. I file binari del journal sono gestiti direttamente da systemd-journald. Usa le impostazioni relative a dimensioni e conservazione di journald e le operazioni di pulizia di journalctl.

Posso conservare i log su un altro HDD?

Sì, tramite l'inoltro dei log o un mount progettato appositamente, ma journald non offre un'impostazione per un percorso personalizzato arbitrario. La registrazione remota è generalmente più sicura rispetto allo spostamento di una directory fondamentale del sistema operativo.

Perché il journal ha raggiunto diversi gigabyte?

La policy predefinita può consentire una quantità di spazio considerevole e un singolo servizio rumoroso può generare rapidamente molte voci. Controlla sia il limite configurato sia il servizio che produce il volume.