- Standard-Logrotate rotiert Dateien, aber Datenbanken brauchen danach ein Signal zum Neuöffnen.
- Ohne
postrotateschreibt der Prozess weiter in die rotierte Datei – Speicher wächst unkontrolliert. - Eigene Blöcke gehören nach
/etc/logrotate.d/, nie in/etc/logrotate.conf. - Immer erst
logrotate -d(Trockenlauf), dannlogrotate -fzum echten Test. - Rechte nach Rotation prüfen:
create 640 mysql admverhindert Rechte-Chaos.
Warum eine individuelle Konfiguration unverzichtbar ist
Die Voreinstellung vieler Distributionen rotiert Logs zuverlässig, doch sie kennt Ihre Anwendung nicht. Sobald eine Datenbank, ein Container oder ein Java-Dienst ins Spiel kommt, reicht das Schema „umbenennen und komprimieren“ nicht mehr aus. Der Grund ist technisch unspektakulär, aber folgenreich: Ein laufender Prozess hält einen Dateideskriptor auf die ursprüngliche Protokolldatei. Wird diese umbenannt, schreibt der Prozess munter in den umbenannten Inode weiter. Die neu erzeugte Datei bleibt leer, das Log „verschwindet“ scheinbar, und die alte Datei wächst unbegrenzt weiter.
Kurz gesagt :
- Ohne postrotate schreibt ein laufender Datenbankprozess weiter in die rotierte Datei, wodurch Speicher unkontrolliert wächst.
- Eigene Logrotate-Blöcke gehören nach /etc/logrotate.d/, nie in /etc/logrotate.conf.
- Immer erst logrotate -d (Trockenlauf), dann logrotate -f zum echten Test.
- Rechte nach Rotation mit create 640 mysql adm prüfen, um Rechte-Chaos zu verhindern.
Ich habe in Audits bei französischen Kunden mehrfach gesehen, dass eine einzige fehlende Zeile im postrotate-Block über Monate hinweg mehrere Gigabyte Plattenplatz gefressen hat. Auf einem Root-Server bei OVHcloud oder Scaleway ist das kein theoretisches Risiko, sondern ein Vorfall mit Ticket. Deshalb betrachten wir Logrotate hier nicht als Nebensache der Systemverwaltung, sondern als Teil der Architektur.
Wie funktioniert Logrotate unter Linux und Unix grundlegend?
Logrotate ist ein zustandsloses Werkzeug, das Konfigurationsdateien sequenziell abarbeitet und dabei pro Block genau eine Logdatei-Gruppe verwaltet. Es wird üblicherweise täglich durch einen systemd-Timer oder einen Cron-Job gestartet, liest die Hauptkonfiguration /etc/logrotate.conf und danach alle Dateien im Verzeichnis /etc/logrotate.d/. Jeder Block beginnt mit einem oder mehreren Pfaden und enthält in geschweiften Klammern die Direktiven.
/var/log/meine-anwendung/*.log { taeglich rotate 7 compress missingok notifempty
}Die wichtigsten Direktiven, die wir in der Praxis wirklich brauchen, sind schnell aufgezählt. Ich beschränke mich hier auf die, die den Unterschied machen:
daily,weekly,monthly: legt den Rotationsrhythmus fest.rotate N: Anzahl der aufbewahrten Generationen.compressunddelaycompress: Gzip-Komprimierung, verzögert um einen Zyklus.missingokundnotifempty: unterdrücken Fehler bei fehlenden oder leeren Dateien.create 640 mysql adm: legt Modus und Eigentümer der neuen Datei fest.sharedscripts: führtpostrotatenur einmal für die gesamte Gruppe aus.
Unter Debian und Ubuntu liegt die Hauptdatei unter /etc/logrotate.conf, unter AlmaLinux und RHEL finden Sie zusätzlich /etc/logrotate.d/ mit distributionsspezifischen Blöcken. Prüfen Sie diese Voreinstellungen, bevor Sie eigene Einträge ergänzen – sonst überrascht Sie ein bereits vorhandener Block für dieselbe Datei.
Wie identifiziere ich die richtigen Logdateien einer Anwendung?
Bevor Sie eine Direktive schreiben, müssen Sie wissen, welche Datei Ihre Anwendung tatsächlich öffnet; das klingt trivial, ist aber die häufigste Fehlerquelle in der Systemverwaltung. Gehen Sie systematisch vor:
- Lesen Sie die Dokumentation der Anwendung und notieren Sie die Standardpfade.
- Prüfen Sie mit
ps auxdie laufenden Prozesse und deren Parameter. - Nutzen Sie
lsof -p PID, um alle geöffneten Dateideskriptoren zu sehen. - Suchen Sie mit
find /var/log -name "*.log"nach weiteren Kandidaten. - Kontrollieren Sie die Anwendungskonfiguration auf benutzerdefinierte Pfade.
PostgreSQL schreibt üblicherweise nach /var/log/postgresql/, MySQL nach /var/log/mysql/, MongoDB nach /var/log/mongodb/mongod.log. Bei geclusterten Datenbanken kommt erschwerend hinzu, dass jeder Knoten eigene Dateien besitzt – ein zentraler Logrotate-Block auf allen Knoten ist dann Pflicht, nicht Kür.
Wie erstelle ich einen dedizierten Konfigurationsblock?
Legen Sie eine eigene Datei unter /etc/logrotate.d/ an, etwa /etc/logrotate.d/meine-datenbank, und lassen Sie bestehende Dateien unangetastet. Ein robustes Beispiel für MySQL sieht so aus:
/var/log/mysql/mysql-error.log /var/log/mysql/mysql-slow.log { daily rotate 14 compress delaycompress missingok notifempty create 640 mysql adm sharedscripts postrotate systemctl reload mysql > /dev/null 2>&1 || true endscript
}Die Direktive delaycompress ist hier kein Detail: Sie verschiebt die Komprimierung um einen Zyklus, damit die Anwendung noch in die vorherige Datei schreiben kann, falls sie das Signal nicht sofort verarbeitet. Das || true am Ende verhindert, dass ein fehlgeschlagenes Reload den gesamten Logrotate-Lauf abbricht.
Welches Signal braucht welche Anwendung?
Der postrotate-Block ist der kritischste Teil jeder Konfiguration, weil er entscheidet, ob die Anwendung ihre Dateihandles neu öffnet oder nicht. Drei Methoden haben sich bewährt:
- systemd-Reload:
systemctl reload dienst– sauberste Variante für moderne Dienste. - POSIX-Signal:
kill -USR1 $(cat /var/run/dienst.pid)– klassisch, aber empfindlich bei falscher PID. - Anwendungsspezifische Werkzeuge: etwa
mysqladmin flush-logsbei MySQL.
Für PostgreSQL nutze ich in der Regel pg_ctl reload mit explizitem Datenverzeichnis, für MongoDB genügt ein kill -SIGUSR1 an die PID aus /var/run/mongodb/mongod.pid. Wichtig: Wenn Sie systemctl reload verwenden, prüfen Sie vorher mit systemctl cat dienst, ob der Dienst überhaupt eine Reload-Aktion definiert – sonst schlägt der Aufruf still fehl.
| Methode | Beispiel | Vorteile | Nachteile |
|---|---|---|---|
| systemd-Reload | systemctl reload mysql | Rechte sauber, kein PID-Parsing, idempotent | Funktioniert nur bei definierter Reload-Aktion |
| POSIX-Signal | kill -USR1 $(cat pid) | Universell, funktioniert auch ohne systemd | Falsche oder fehlende PID bricht den Lauf ab |
| Anwendungstool | mysqladmin flush-logs | Vom Hersteller vorgesehen, präzise | Nur für bestimmte Anwendungen verfügbar |
| copytruncate | copytruncate | Kein Signal nötig, einfach | Race Condition möglich, nicht atomar bei hoher Last |
Franchement, ich halte copytruncate für einen Notnagel. Es kopiert die Datei und leert anschließend das Original – zwischen Kopie und Truncate können Logzeilen verloren gehen. Bei Datenbanken mit Transaktionslogs ist das inakzeptabel.
Wie teste ich die Konfiguration, ohne Schaden anzurichten?
Testen Sie jede neue Konfiguration zunächst im Debug-Modus, der alle Aktionen simuliert, ohne Dateien zu verändern. Der Aufruf lautet logrotate -d /etc/logrotate.d/meine-datenbank. Prüfen Sie in der Ausgabe, ob alle Pfade erkannt werden und ob der postrotate-Block korrekt ausgeführt würde. Danach folgt ein erzwungener Durchlauf mit logrotate -f /etc/logrotate.d/meine-datenbank, um die echte Rotation zu verifizieren.
Achten Sie dabei auf drei Dinge: Werden die neuen Dateien mit den korrekten Rechten erstellt? Öffnet die Anwendung nach dem Signal wirklich eine neue Datei? Und verschwinden alte Generationen nach Ablauf der Aufbewahrungsfrist? Mit ls -la und lsof sehen Sie das in wenigen Sekunden. Bei mir hat dieser Check schon mehrfach verhindert, dass ein falsch gesetztes create die Datenbank nach der Rotation schreibunfähig gemacht hat.
Wie automatisiere und überwache ich die Rotation?
In den meisten Installationen übernimmt bereits ein systemd-Timer die Ausführung; prüfen Sie den Status mit systemctl status logrotate.timer und aktivieren Sie ihn bei Bedarf mit systemctl enable --now logrotate.timer. Für die Überwachung empfehle ich, die Logrotate-Ausgabe in eine eigene Datei zu schreiben und regelmäßig auszuwerten. Ein Monitoring-Werkzeug wie Zabbix, Prometheus oder das französische Centreon kann Sie benachrichtigen, wenn eine Rotation fehlschlägt oder eine Protokolldatei ungewöhnlich schnell wächst.
Ein Punkt, den viele übersehen: Logrotate selbst kennt keinen Zustand über Läufe hinweg außer der Datei /var/lib/logrotate/status. Wenn diese Datei bei einem Container-Rebuild verloren geht, rotiert Logrotate möglicherweise mehrfach am selben Tag. Binden Sie das Statusverzeichnis daher in ein persistentes Volume ein.
Welche Fehler sehe ich in Audits am häufigsten?
Selbst erfahrene Administratoren tappen in dieselben Fallen, weil die Symptome erst Wochen später sichtbar werden. Diese Liste deckt den Großteil der Vorfälle ab, die mir begegnet sind:
- Fehlendes Reload-Signal: Die Anwendung schreibt weiter in die rotierte Datei, Speicher wächst unkontrolliert.
- Falsche Berechtigungen: Neue Dateien gehören
root, die Anwendung kann nicht mehr schreiben. - Zu kurze Aufbewahrung: Bei Aufbewahrungspflichten – in Frankreich etwa im Rahmen der DSGVO-Vorgaben und der CNIL-Empfehlungen – werden Logs zu früh gelöscht.
- Wildcards ohne
sharedscripts: Das Skript läuft mehrfach, was unnötige Neustarts auslöst. - Änderungen in
/etc/logrotate.conf: Diese werden bei Updates überschrieben; nutzen Sie immer/etc/logrotate.d/.
Ein Kunde kontaktierte mich wegen genau dieses letzten Punktes: Nach einem Distributions-Upgrade war seine Anpassung verschwunden, und die Logs wuchsen wieder ungebremst. Seitdem lege ich jede Anpassung ausschließlich als eigene Datei ab – das ist eine Gewohnheit, die sich sofort auszahlt.
Häufig gestellte Fragen zur Logrotate-Konfiguration
Was passiert, wenn ich kein Reload-Signal setze?
Die Anwendung behält ihren Dateideskriptor auf die ursprüngliche Datei und schreibt nach der Rotation weiter in die umbenannte Datei, während die neue Datei leer bleibt. Logs scheinen zu verschwinden, und der Speicherplatz wächst durch die stetig größer werdende rotierte Datei unkontrolliert.
Wie oft sollte ich Logs für Datenbanken rotieren?
Für stark frequentierte Datenbanken empfehle ich eine tägliche Rotation mit 14 bis 30 aufbewahrten Generationen, bei geringer Last genügt eine wöchentliche Rotation. Richten Sie sich nach den Vorgaben Ihrer Compliance-Abteilung, sobald personenbezogene Daten verarbeitet werden.
Kann ich Logrotate für Docker-Container verwenden?
Ja, mit Einschränkungen: Da Container eigene Dateisysteme besitzen, müssen Sie die Logdateien über ein Volume auf den Host mounten oder die integrierte Docker-Logrotation nutzen. Für Kubernetes bietet sich ein Sidecar-Container mit Logrotate an.
Wie prüfe ich, ob meine Konfiguration funktioniert?
Nutzen Sie logrotate -d für einen Trockenlauf und logrotate -f für einen erzwungenen Durchlauf. Kontrollieren Sie anschließend mit ls -la die neuen Dateien und mit lsof, ob die Anwendung die neuen Deskriptoren geöffnet hat.
Wo finde ich die Standardkonfiguration unter Debian und Ubuntu?
Die Hauptkonfiguration liegt unter /etc/logrotate.conf, anwendungsspezifische Blöcke im Verzeichnis /etc/logrotate.d/. Unter Debian-basierten Systemen führt der systemd-Timer logrotate.timer die Rotation standardmäßig aus.
Warum ist delaycompress bei Datenbanken sinnvoll?
delaycompress verschiebt die Komprimierung um einen Zyklus, damit die Anwendung noch in die vorherige Datei schreiben kann. Das verhindert Fehler, wenn ein Dienst das Reload-Signal verzögert verarbeitet und kurzzeitig weiter in die alte Protokolldatei schreibt.
Was ich Ihnen zum Abschluss mitgeben möchte
Eine durchdachte Logrotate-Konfiguration ist mehr als eine administrative Pflichtübung. Sie schützt Ihre Daten, hält die Speichernutzung skalierbar und erleichtert die Fehlersuche erheblich. Die entscheidenden Stellschrauben sind das richtige Reload-Signal, saubere Dateirechte und ein Testlauf vor dem Produktiveinsatz. Prüfen Sie Ihre bestehenden Konfigurationen noch heute – Ihre Systemressourcen und Ihr zukünftiges Ich werden es Ihnen danken.
Gerade bei Datenbanken können Logdateien schnell gigantische Ausmaße annehmen, was eine gezielte Logrotate-Performance-Optimierung unerlässlich macht.
Sollten nach der Rotation Probleme auftreten, hilft eine Anleitung zum Beheben von Logrotate postrotate Skript Fehlern, die Ursache schnell zu finden.
Für komplexe Umgebungen, in denen Datenbanken auf mehreren Servern laufen, ist die Konfiguration von Logrotate für verteilte Systeme entscheidend.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
