Logwachstum begrenzen und freigegebenen Speicher prüfen

Datenbankschreibvorgänge können fehlschlagen, obwohl keine neuen Anwendungsdateien auf der Festplatte hinzugekommen sind. Eine häufige Ursache sind ständig wiederholte Fehlermeldungen, die das Fehlerlog anwachsen lassen, bis die Systempartition voll ist. Logwachstum zu begrenzen bedeutet nicht, regelmäßig Verzeichnisse zu löschen: Schreibaufkommen, Rotation und Aufbewahrung müssen getrennt gesteuert werden. Anschließend ist zu prüfen, ob der Speicher tatsächlich freigegeben wurde. Dieser Beitrag behandelt am Beispiel von Debian 12 das Systemjournal und die dateibasierten Logs kurz laufender Aufgaben, ohne Datenbankdateien oder die bestehende Speicheraufteilung zu verändern.

Die Dedicated Server von CloudSFP sind standardmäßig mit zwei direkt angebundenen NVMe-Laufwerken mit jeweils 1TB ausgestattet, ohne Hardware-RAID. Ihre Gesamtkapazität sagt nicht aus, wie viel Platz im Dateisystem der Logs noch verfügbar ist. Das Logbudget muss sich nach dem tatsächlichen Einhängepunkt richten. Alle folgenden Kapazitätswerte sind Beispiele für die Einrichtung, keine Standardeinstellungen des Dienstes.

1. Belegung ermitteln und Datenblöcke von Inodes unterscheiden

Rufen Sie nach der Zahlung die Zugangsdaten in der Konsole ab und melden Sie sich per SSH an. Hat der Server mehrere Adressen, verwenden Sie die erste. Beginnen Sie mit diesen rein lesenden Prüfungen:

df -hT / /var/log
df -i / /var/log
findmnt -T /var/log
sudo du -xhd1 /var/log
sudo journalctl --disk-usage

df zeigt die Belegung des Dateisystems, während du die im Verzeichnis sichtbaren Dateien erfasst. Die Ergebnisse müssen nicht übereinstimmen. Mit -x werden andere Dateisysteme nicht durchlaufen. Dadurch sinkt das Risiko, separat eingehängte Volumes in die Auswertung einzubeziehen. Liegt /var/log nicht auf einer eigenen Partition, teilen sich die Logs den Platz auf der Root-Partition mit den Systemdateien.

Ist noch ausreichend Speicherplatz vorhanden, sind die Inodes aber fast aufgebraucht, suchen Sie nach vielen kleinen Dateien statt nur nach den größten Logs. Halten Sie Dateisystem, verfügbaren Speicher, Inode-Belegung und die am schnellsten wachsenden Verzeichnisse fest, bevor Sie entscheiden, wo Sie eingreifen. Schreiben Sie die Diagnoseaufzeichnungen nicht auf eine bereits nahezu volle Partition.

Löschen Sie nicht das gesamte Verzeichnis /var/log und kürzen Sie keine Fehlerlogs, bevor diese gesichert wurden. Bewahren Sie vor der Bereinigung die Nachweise für den relevanten Zeitraum auf und stellen Sie sicher, dass es sich beim Ziel nicht um Datenbankdaten, Transaktionslogs oder Sicherungsdateien handelt.

2. Ein eigenes Speicherbudget für journald festlegen

Persistente Journaldateien liegen üblicherweise unter /var/log/journal. Grenzen über eine Drop-in-Konfiguration zu verwalten, ist leichter nachzuvollziehen und rückgängig zu machen als das Überschreiben der Hauptkonfiguration. Das folgende Beispiel legt ein Speicherbudget für das Journal fest und reserviert freien Platz im Dateisystem:

sudo install -d -m 0755 /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/60-capacity.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=4G
MaxFileSec=1day
EOF

sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
sudo journalctl --flush
sudo journalctl --disk-usage
sudo systemctl status systemd-journald --no-pager

SystemMaxUse steuert das Speicherbudget des Journals. SystemKeepFree legt fest, wie viel Platz auf demselben Dateisystem frei bleiben soll. Das tatsächliche Verhalten hängt auch vom aktuell verfügbaren Speicher ab. Dateien, die Anwendungen selbst schreiben, werden dadurch nicht begrenzt. MaxFileSec bestimmt die maximale Zeitspanne einer aktiven Datei und bedeutet nicht, dass nur die Logs eines Tages aufbewahrt werden.

Schreibt ein anderes Programm dieselben Meldungen zusätzlich in Textlogs, verschwindet diese zweite Kopie nicht durch eine Begrenzung des Journals. Prüfen Sie die Protokollierungskette und verwalten Sie die einzelnen Ziele getrennt. Deaktivieren Sie den Systemprotokolldienst nicht, ohne zuvor seine Verwendung zu prüfen.

Vor der Bereinigung rotieren, danach das Ergebnis prüfen

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G
sudo journalctl --disk-usage
df -h /var/log

Die Vacuum-Funktion löscht nur archivierte Dateien, nicht direkt die aktiven Dateien. Deshalb entspricht die verbleibende Belegung nicht zwangsläufig exakt dem angegebenen Wert. Der Neustart von journald gehört zur Konfigurationsänderung: Prüfen Sie vorher den aktuellen Dienststatus und anschließend, ob neue Fehler aufgetreten sind und die Anwendungslogs weiterhin im Journal ankommen.

3. Zuständigkeit für die Rotation von Logdateien eindeutig festlegen

Klären Sie zunächst, welches Programm die Logs schreibt, ob es die Datei dauerhaft geöffnet hält und ob bereits eine Regel den betreffenden Pfad abdeckt. Dieselbe Datei darf nicht gleichzeitig durch die anwendungseigene Rotation und logrotate verwaltet werden. Fügen Sie auch keine weit gefassten Muster hinzu, die vorhandene Systemregeln doppelt abdecken.

Installieren Sie die Prüfwerkzeuge:

sudo apt-get update
sudo apt-get install logrotate lsof

Angenommen, eine kurz laufende Aufgabe öffnet /var/log/local-batch/run.log bei jedem Start neu und schließt die Datei nach Abschluss. Dann können Sie in /etc/logrotate.d/local-batch Folgendes eintragen:

/var/log/local-batch/run.log {
    daily
    maxsize 100M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640
}

Das Verzeichnis und die ursprüngliche Logdatei müssen bereits vorhanden sein. Die Eigentumsverhältnisse müssen zum Konto der Aufgabe passen. Ohne Angabe eines Eigentümers übernimmt create 0640 Eigentümer und Gruppe der ursprünglichen Datei. Darf ein unprivilegiertes Konto in das Verzeichnis schreiben, müssen die su-Direktive und die Verzeichnisrechte gesondert geprüft werden. Übernehmen Sie die Regel in diesem Fall nicht unverändert.

sudo logrotate -d /etc/logrotate.conf
systemctl list-timers --all --no-pager

-d zeigt nur einen Probelauf an und führt keine Rotation aus. Prüfen Sie, wie häufig der Timer oder Cronjob tatsächlich läuft: maxsize wird nur beim Aufruf von logrotate geprüft und ist keine in Echtzeit durchgesetzte harte Grenze. rotate 7 bewahrt sieben Archive auf, was ebenfalls nicht zwangsläufig sieben Tagen entspricht.

Dauerhaft laufende Prozesse benötigen einen von der Anwendung unterstützten Mechanismus zum erneuten Öffnen der Logs. Nach dem Umbenennen einer Datei kann der Prozess weiterhin in die alte Datei schreiben. Raten Sie nicht, welches Signal dafür nötig ist, und verwenden Sie copytruncate nicht als Standardlösung. Zwischen Kopieren und Kürzen besteht ein Zeitfenster, in dem Logeinträge verloren gehen können.

4. Rotation und Berechtigungen in einem isolierten Verzeichnis testen

Testen Sie neue Regeln nicht durch eine erzwungene Rotation mit der globalen Konfiguration. Der folgende Versuch verwendet ein separates Verzeichnis und eine eigene Statusdatei; Produktionslogs bleiben unberührt:

umask 077
test_dir=$(mktemp -d)
printf '%0200d\n' $(seq 1 20) >"$test_dir/run.log"

cat >"$test_dir/rules" <<EOF
"$test_dir/run.log" {
    size 1k
    rotate 2
    create 0640
}
EOF

logrotate -d -s "$test_dir/state" "$test_dir/rules"
logrotate -s "$test_dir/state" "$test_dir/rules"
ls -l "$test_dir"
printf 'after rotation\n' >>"$test_dir/run.log"
cat "$test_dir/run.log"

Es sollten eine Archivdatei, eine neu angelegte aktive Datei und die erwarteten Berechtigungen zu sehen sein. Der letzte Schreibvorgang belegt lediglich, dass sich der Pfad erneut öffnen lässt. Er beweist nicht, dass eine dauerhaft laufende Anwendung automatisch auf die neue Datei wechselt. Zur Abnahme im Produktionsbetrieb muss außerdem die tatsächliche Aufgabe einen eindeutig erkennbaren Eintrag erzeugen, der anschließend in der neuen aktiven Datei nachgewiesen wird.

Bewahren Sie das Testverzeichnis zur Prüfung der Ergebnisse auf und löschen Sie es nach deren Bestätigung. Produktionsregeln werden weiterhin über die vorhandene Statusdatei des Systems verwaltet. Lassen Sie manuelle Aufrufe und geplante Aufgaben nicht gleichzeitig laufen und verwalten Sie dasselbe Log nicht dauerhaft mit zwei Statusdateien.

5. Speicherfreigabe prüfen und wiederholte Fehler beheben

Wenn nach dem Löschen von Dateien nicht mehr Speicher verfügbar ist, prüfen Sie zunächst, welche Dateien noch von Prozessen geöffnet gehalten werden:

sudo lsof +L1
df -h /var/log
df -i /var/log
sudo du -xhd1 /var/log

lsof +L1 listet geöffnete Dateien mit einer Linkanzahl kleiner als eins auf. Beurteilen Sie die Einträge anhand von Pfad, Größe und Prozess; nicht jedes Ergebnis ist eine Logdatei. Öffnen Sie nach eindeutiger Identifizierung des Ziels das Log gemäß der Anwendungsdokumentation erneut. Starten Sie bei Bedarf den zugehörigen Dienst neu und prüfen Sie anschließend nochmals mit df. Erzwingen Sie die Speicherfreigabe nicht, indem Sie unbekannte Prozesse beenden oder in deren Dateideskriptoren schreiben.

Halten Sie bei der Abnahme mindestens vier Ergebnisse fest: Neue Einträge landen in der aktiven Datei, die Anzahl der Archive entspricht der Regel, das Konto kann weiterhin schreiben und der freie Speicher im Dateisystem nimmt nicht fortlaufend ungewöhnlich stark ab. Wiederholen sich Fehlermeldungen weiterhin in großen Mengen, beheben Sie die Ursache fehlgeschlagener Wiederholungsversuche, ungültiger Anfragen oder der Debug-Ausgaben. Rotation ersetzt keine Fehlerbehebung.

Ein Speicherbudget garantiert auch keinen festen Zeitraum für die Loghistorie. Bei Lastspitzen wachsen die Logs schneller, sodass ältere Einträge bei gleichem Budget früher entfernt werden. Für langfristig aufzubewahrende Nachweise müssen Übertragung, Zugriffskontrolle und Sicherung separat geplant und das tatsächliche Auslesen überprüft werden. Lokale Logrotation begrenzt lediglich die lokale Speicherbelegung; sie übernimmt keine Backup-Funktion.

Häufig gestellte Fragen