root File System Voll?

Welche Maßnahmen sind sinnvoll? und welche Reihenfolge nutze ich.

Root-Partition voll: an journalctl --vacuum-* denken

Wenn / (Root) mal wieder zu voll ist, ist systemd-journald ein üblicher Verdächtiger: Logs sammeln sich an, besonders auf Kisten, die lange laufen oder viel quatschen (Docker, Kernel-Spam, NetworkManager, …).

Symptome prüfen

df -h /

erste Hilfe Maßnahmen:

• apt clean Effekt: ggfs. Deutlich spürbar
  löscht alte runtergeladene Debianpakete, die Debian nicht selbsttätig löscht.
  Dies bringt oftmals schon erhebliche Erleichterung, gerne auch einige GB!
• apt autoremove Effekt: kaum spürbar
  Entfernt Pakete, die nur irgendwann wegen Abhängigkeiten mit installiert wurden
  und unbesorgt entfernt werden können
• ncdu -x / Falls bereits installiert
  Liefert Hinweise wo noch Platzverschwender lauern.
  zu Flatpak und docker gehe ich später noch ein. (derzeit fehlt es noch)

Wie groß ist das Journal?

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

Beispiel:

df -h /
Dateisystem              Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/p15--vg-root   76G     63G  9,5G   87% /

• Schnell Platz schaffen: Vacuum Effekt: ggfs. Deutlich spürbar
  Nach Zielgröße begrenzen
  journalctl --vacuum-size=50M

• Alternativ: nach Zeit begrenzen
  journalctl --vacuum-time=7d

• Oder: nur bis eine Anzahl Files übrig ist
  journalctl --vacuum-files=5

Beispiel-Ergebnis:

df -h /
Dateisystem              Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/p15--vg-root   76G     59G   14G   82% /

Dauerhaft sinnvoll einstellen (statt immer wieder löschen)

Konfig liegt hier:

nano /etc/systemd/journald.conf

Nützliche Optionen (Beispiele):

SystemMaxUse=200M
SystemKeepFree=1G
MaxRetentionSec=7day

Danach Journald neu laden:

systemctl restart systemd-journald

Hinweise / Fallstricke

Vacuum löscht alte Logs. Wenn du gerade ein Problem debuggen willst: erst überlegen, dann löschen.

Wenn /var/log/journal/ existiert, wird persistent geloggt (normal und ok), aber dann wächst es halt auch wirklich.

Wenn du nur “kurz Platz brauchst”, ist --vacuum-size meist der beste Hammer.

Journald-Limits auf Root-Servern (Praxisbeispiel)

Auf Root-Servern mit ausreichend Platz und höherem Debug-Bedarf können die Limits großzügiger gesetzt werden:

SystemMaxUse=800M
SystemKeepFree=2G
MaxRetentionSec=31day

Warum das sinnvoll ist:

SystemMaxUse=800M
Genug Historie für:
Kernel-Updates;sporadische Fehler

Security-Events (Fail2ban, SSH, sudo)
Ohne dass das Journal ausufert.

SystemKeepFree=2G
Sehr wichtig: selbst wenn Logs explodieren, bleibt / benutzbar.
Das ist der eigentliche Lebensretter.

MaxRetentionSec=31day / oder 21day
Drei Wochen sind ein guter Kompromiss:

lang genug für Ursachenanalyse

kurz genug, um kein Log-Archiv zu werden