Logrotation unter Linux optimieren: Präzise Strategien mit logrotate

Wenn in der Nacht die Server weiter Protokolle schreiben, wird deutlich, dass hinter jeder rotierten Logdatei eine knappe Entscheidung steckt: Wie viel Historie bleibt, wie viel Speicherplatz wird benötigt und wie zuverlässig lassen sich Vorfälle nachverfolgen? Logrotation unter Linux läuft nicht als Dauerdaemon, sondern wird typischerweise durch Cron oder systemd‑Timer gestartet und folgt Kernprinzipien wie vorhersagbarer Rotation, deterministischer Historie und zentraler Statusverfolgung. Um Chaos zu verhindern, braucht es eine präzise Abstimmung zwischen globalen Defaults in der Hauptkonfiguration und app‑spezifischen Regeln in /etc/logrotate.d.

Dieser Beitrag skizziert eine praxisnahe Roadmap: Wie man dateext/dateformat sinnvoll verwendet, wie Sharedscripts und Postrotate‑Blöcke koordiniert werden und wie zeit‑ und größenbasierte Trigger ineinandergreifen, um Lastspitzen zu bändigen. Sie erfahren, wie globale Standards mit dienstspezifischen Overrides harmonieren, welche Rolle copytruncate versus postrotate spielen und wie Dry‑Run‑Tests Fehler schon vor dem Live‑Betrieb aufdecken. Am Ende stehen klare Strategien, die Stabilität, Nachvollziehbarkeit und effizienten Speicherverbrauch zuverlässig verbinden.

Logrotate-Architektur: Kernprinzipien, Pfade und Statusverfolgung

Grundprinzipien der Logrotation

• Kein Daemon: Logrotate läuft nicht dauerhaft im Hintergrund. Typischerweise wird es durch Cron oder einen systemd‑Timer täglich gestartet, liest seine Konfiguration und führt Rotationen aus.
• Vorhersagbare Rotation: Durch festgelegte Intervalle (z. B. daily, weekly, monthly) sowie definierte Kriterien steuert logrotate, wann eine Datei rotiert wird und wann sie unverändert bleibt.
• Deterministische Historie: Dank der Statusverfolgung wird vermieden, dass dieselbe Protokolldatei mehrfach im gleichen Zyklus rotiert wird; dadurch bleibt die Historie konsistent nachvollziehbar.

Diese Kernprinzipien bilden die Grundlage für die folgenden Abschnitte zu Pfaden, Statusverfolgung und Rotationsablauf.

Konfigurationspfade und Include-Verweise

• Globale Standards in /etc/logrotate.conf: Die Datei legt das Standardverhalten fest und dient als Basis, auf der alle app‑spezifischen Regeln aufbauen.
• App-spezifische Regeln in /etc/logrotate.d: Zusätzliche Konfigurationen zu einzelnen Diensten werden in separaten Dateien abgelegt, beispielsweise für nginx, apache2, rsyslog etc.
• Include‑Verweise: Die globale Konfiguration führt typischerweise include /etc/logrotate.d aus, wodurch die dort definierten Blöcke automatisch geladen werden.
• Pfad‑Beispiele: In der Praxis finden sich dort Regeln, die auf Dateien in /var/log zeigen, während Dienste oft eigene Verzeichnisse wie /var/log/nginx/ oder /var/log/apache2/ bedienen.

Auf dieser Pfad‑Ebene setzt sich die Logik fort – die Zuweisung von Regeln zu bestimmten Logdateien bildet die Grundlage für zielgerichtete Rotationen.

Statusverfolgung und Rotationslogik

• Speicherort des Status: Der Prozess hält Informationen über die zuletzt erfolgten Rotationen in /var/lib/logrotate/status fest.
• Zweck des Status: Die Statusdatei verhindert unnötige Rotationen am gleichen Tag und sorgt dafür, dass logrotate Rotationen nur durch Zeitfenster, Dateigröße oder andere Kriterien gerechtfertigt ausführt.
• Was der Status enthält: Einträge pro Logdatei mit dem Datum bzw. Zyklus, wann zuletzt rotiert wurde, damit logrotate beim nächsten Lauf weiß, ob eine Rotation fällig ist.

Im Status spiegelt sich die Koordination der Rotationen wider, die später auch den detaillierten Ablauf steuert.

Rotationsablauf im Detail

• Umbenennung der aktuellen Datei: Die laufende Logdatei wird umbenannt (z. B. logfile.log → logfile.log.1).
• Erstellung einer neuen leeren Datei: Direkt danach wird eine neue Datei mit dem ursprünglichen Namen erzeugt, damit der Dienst weiter schreiben kann.
• Optionale Kompression der Archive: Archivierte Dateien können automatisch komprimiert werden, oft mit gzip; alternativ stehen andere Kompressionsprogramme oder Optionen zur Verfügung.
• Standardpfade für Protokolle: Typische Logdateien befinden sich unter /var/log/*; dazu gehören auch cron‑bezogene Logs sowie zentrale Logs wie systemweite Dateien in /var/log.
• Verzögerte Kompression (delaycompress): Die Kompression der vorherigen Rotation wird auf den nächsten Rotationszyklus verschoben, um Konflikte mit laufenden Prozessen zu vermeiden.
• Skripte rund um die Rotation: Vor‑ und Nachrotation‑Skripte (prerotate, postrotate) ermöglichen Dienst‑Neustart oder ‑Neuladen, damit der neue Logdatei‑Handle korrekt genutzt wird.

Auf dieser Detailebene wird sichtbar, wie Statusverfolgung und Rotationslogik in konkreten Abläufen greifen.

Typische Log-Pfade und Dateien

• Standardpfade: /var/log/* deckt die meisten System‑ und Anwendungslogs ab.
• Dienstspezifische Logs: Typische Dienste wie nginx, apache2 oder weitere Softwarepakete legen eigene Konfigurationen in /var/log/* ab.
• Systemweite Logs: Allgemeine Logs, die das Betriebssystem betreffen, befinden sich ebenfalls in /var/log.
• Cron‑ und System‑Logs: Viele Logs befinden sich in Cron‑Verzeichnissen oder systemweiten Logs, die durch die Konfiguration abgedeckt werden.

Kompression und Verzögerung

• Standard‑Kompression: Viele Systeme verwenden gzip als Standardkompressionswerkzeug; der Status der rotierten Dateien lautet typischerweise logfile.log.1.gz, logfile.log.2.gz usw.
• Verzögerte Kompression: Mit delaycompress wird die Kompression der zuletzt rotierten Datei erst bei der nächsten Rotation durchgeführt. Dadurch bleiben offene Dateihandles stabil und Probleme mit schreibenden Prozessen werden vermieden.
• Konsequente Archivierung: Durch das Zusammenspiel von compress und delaycompress lässt sich sicherstellen, dass archivierte Logs platzsparend gespeichert werden, während aktuelle Logs stabil weitergeführt werden.

Feingranularität: Defaults vs. Overrides

• Globale Defaults in /etc/logrotate.conf: Legen ungefähren Rahmen fest (Frequenz, wie viele Versionen beibehalten werden, generelle Kompression, include‑Verweis).
• Service‑spezifische Overrides in /etc/logrotate.d: Erlauben feingranulierte Einstellungen pro Dienst (z. B. unterschiedliche Rotationshäufigkeiten, eigene rotate‑Anzahlen, besondere postrotate‑Befehle).
• Gemeinsame Skripte: Durch sharedscripts können postrotate‑/prerotate‑Blocks pro Rotationseinheit zentral verwaltet werden, ohne dass für jede Datei wiederholt Skripte ausgeführt werden.
• Beispiel‑Szenarien: Ein Webserver könnte täglich rotieren und 14 Archivdateien behalten, während ein Logging‑Agent eine wöchentliche Rotation mit 8 Archivversionen nutzt. Das Zusammenspiel beider Pfade ermöglicht eine präzise Steuerung je Dienst.

Praxis Auswirkungen

• Mit der Architekturlogik von logrotate lassen sich Rotationen sehr granular modellieren: Häufigkeit, Behaltensdauer, Kompression, Ort der Archivierung und Dienst‑Integrationen gehen Hand in Hand.
• Durch klare Trennung von globalen Standards und dienstspezifischen Overrides bleibt die Konfiguration übersichtlich und wartbar.
• Die Statusverfolgung sorgt für Stabilität im täglichen Betrieb und verhindert unnötige Arbeiten, während gleichzeitig genügend Historie erhalten bleibt.

Diese Architektur ermöglicht eine robuste, nachvollziehbare und anpassbare Logrotation in Linux‑Serverumgebungen – ein zentrales Werkzeug zur effizienten Verwaltung von Logs, Speicherplatzbedarf und Administrationsaufwand.

Globale Standards vs app-spezifische Konfiguration: Von logrotate.conf zu /etc/logrotate.d

Globale Direktiven: der gemeinsame Rahmen

• Globale Direktiven legen die Grundregeln fest, z. B. weekly, rotate, compress, create, include. Diese Defaults bilden den gemeinsamen Rahmen, innerhalb dessen Anwendungen ihre Feinabstimmungen vornehmen.
• include verweist auf Dateien in /etc/logrotate.d und sorgt dafür, dass app‑spezifische Konfigurationen automatisch geladen werden. So lassen sich zentrale Prinzipien konsistent auf verschiedene Dienste anwenden.
• Aus dem Zusammenspiel dieser Direktiven ergibt sich eine vorhersehbare Rotationslogik: Häufigkeit der Rotation, Anzahl archivierter Versionen, ob Dateien komprimiert werden sowie standardisierte Zugriffsrechte für neue Dateien.

App-spezifische Konfiguration: /etc/logrotate.d

• App‑spezifische Konfigurationen befinden sich in /etc/logrotate.d und erweitern bzw. überschreiben die globalen Standardwerte, falls nötig. Jede Anwendung kann so eine eigene Rotation definieren, ohne die globale Konfiguration zu verändern.
• Typischer Aufbau: eine Blockdefinition, die Pfad(e) zu Logs der Anwendung angibt, sowie eine Reihe von Direktiven innerhalb geschweifter Klammern, z. B. frequency, rotate‑Anzahl, create/nocreate, sharedscripts, postrotate‑Endmarkierungen.
• In vielen Distributionen werden Protokolle von Webservern, Datenbanken oder Cache‑Systemen in separaten Dateien in /etc/logrotate.d verwaltet, wodurch sich Rotationslogik und Wartung pro Dienst extern regeln lassen.

Datumsbasierte Dateinamen und Formate

• Mit der Direktive dateext erhalten alte Logdateien Datumsstempel im Namen statt rein numerischer Suffixe. Das erleichtert Archivsuche und Klarheit in langen Historien.
• dateformat bestimmt das Format des Datums, z. B. -%Y-%m-%d. Dadurch entstehen lesbare Archivdateien wie
• Die Kombination aus dateext und dateformat erhöht die Nachvollziehbarkeit der Archive, besonders in Umgebungen mit vielen Logs unterschiedlicher Dienste.

Sharedscripts: eine gemeinsame Nachbearbeitung pro Rotation

• Sharedscripts sorgt dafür, dass prerotate‑ und postrotate‑Skripte nur einmal pro Rotation ausgeführt werden, auch wenn mehrere Logdateien von derselben Rotation betroffen sind.
• Ohne Sharedscripts würden prerotate‑ und postrotate‑Skripte potenziell mehrfach pro betroffene Logdatei gestartet, was zu unnützer Last oder unvorhersehbaren Nebeneffekten führen kann.
• Gemeinsame Skripte ermöglichen eine koordinierte Reaktion auf die Rotation, z. B. Neustart oder Neuladen eines Dienstes.

Praxisbeispiele aus der Praxis

• In echten Szenarien finden sich typischerweise Blockdefinitionen für Apache-/Nginx‑Logs, Chrony‑Logs und MySQL‑Logs – jeweils mit eigenen postrotate‑Anweisungen, die Dienste neu laden oder Signale an Daemons senden.
• Beispiel Apache/nginx‑Logs:
• Apache‑Beispiel: /var/log/apache2/*.log { daily; missingok; rotate 14; compress; delaycompress; create 0640 root adm; sharedscripts; postrotate /usr/sbin/apache2ctl graceful > /dev/null 2>/dev/null || true; endscript }
• Nginx‑Beispiel: /var/log/nginx/*.log { daily; rotate 14; compress; delaycompress; missingok; notifempty; create 0640 www-data adm; sharedscripts; postrotate nginx -s reopen 2>/dev/null || true; endscript }
• Chrony‑Logs:
• Beispielkonfiguration: /var/log/chrony/*.log { missingok; nocreate; sharedscripts; postrotate /usr/bin/chronyc cyclelogs > /dev/null 2>&1 || true; endscript }
• MySQL‑Logs:
• /var/log/mysql/*.log { daily; rotate 7; missingok; create 640 mysql adm; compress; sharedscripts; postrotate if test -f /var/run/mysqld/mysqld.pid; then /bin/kill -HUP $(cat /var/run/mysqld/mysqld.pid); fi; endscript }

Create vs. copytruncate: zwei gängige Muster

• Create: Direkt nach der Rotation wird eine neue Logdatei mit demselben Namen erstellt, inklusive Modus, Besitzer und Gruppe. Vorteil: verhindert Race‑Conditions, da der Daemon im Normalfall sofort auf die neue Datei weiterschreibt.
• Copytruncate: Die Logdatei wird kopiert, danach die Originaldatei auf 0 Bytes gekürzt. Vorteil: einfacher für Anwendungen, die nicht auf Log‑Datei‑Neumeldungen reagieren müssen; Nachteil: ein kurzes Zeitfenster, in dem neue Logs in die Originaldatei schreiben und damit im Archiv fehlen können; Race‑Conditions bleiben möglich.
• Welches Muster gewählt wird, hängt von der Anwendung ab: create ist in der Regel die sicherere Standardlösung; copytruncate eignet sich eher, wenn die Anwendung keine Reload‑Signale annehmen kann.

Schutz vor Race-Conditions: fehlendes nocreate oder falsches Kopieren

• Durch das Fehlen von nocreate oder durch falsches Kopieren kann es passieren, dass Schreibprozesse in die falsche Datei schreiben oder dass Logs in der rotierten Datei verloren gehen.
• Wichtige Schutzmaßnahmen:
• Verwenden Sie create, um eine konsistente Neuanlage der Datei sicherzustellen, und vermeiden Sie offene Dateideskriptor‑Probleme.
• Falls die Anwendung kein Reload‑Signal unterstützt, kann copytruncate eine praktikable Alternative sein; minimieren Sie in diesem Fall das Rotationsfenster durch geeignete Timing‑ und Logging‑Strategien.
• Bei fehlerhaften Neuanlagen oder Signalen helfen postrotate‑Skripte, die Dienste sauber neu zu signalisieren oder neu zu starten, damit die Weiterleitung der Logs ordnungsgemäß erfolgt.
• Prüfen Sie regelmäßig den Status der Rotation und testen Sie Konfigurationen im Debug‑Modus, um sicherzustellen, dass keine Write‑Backlog‑ oder Race‑Situationen auftreten.

Fazit: Die Balance zwischen globalen Defaults und Dienst-spezifischer Feineinstellung

• Globale Standards definieren konsistente Grundregeln, die den Betrieb vereinfachen und eine verlässliche Basis schaffen.
• App‑spezifische Konfigurationen ermöglichen es, der konkreten Logging‑Verhaltensweise einzelner Dienste gerecht zu werden, etwa in Bezug auf postrotate‑Aktionen, Signalisierung oder spezielle Pfade.
• Die kluge Kombination aus dateext/dateformat, sharedscripts, create oder copytruncate sowie klaren postrotate‑Anweisungen ermöglicht eine stabile, nachvollziehbare Logrotation – ohne Einbußen in Verfügbarkeit oder Datensicherung.

Zeit- und Grössenbasierte Rotation kombinieren: daily/weekly vs size/minsize/maxsize

Die Logrotation folgt zwei Achsen: dem zeitlichen Rhythmus und der Dateigröße. Eine durchdachte Kombinationsstrategie nutzt beides, um Rotationen sinnvoll zu verteilen, Lastspitzen zu entzerren und dennoch zuverlässige Archivierung sicherzustellen. Diese Grundlagen führen direkt zu den verfügbaren Größenoptionen, die im nächsten Abschnitt im Überblick dargestellt werden.

Grundprinzipien: Zeit vs. Größe

• Zeitbasierte Rotation (daily, weekly, monthly) legt fest, wann typischerweise archiviert wird. Sie sorgt für planbare Schreibfenster, minimiert gleichzeitige Rotationen und erleichtert Wartungsfenster.
• Größenbasierte Rotation (size, minsize, maxsize) reagiert auf akute Log‑Volumina. Sie hilft, Lastspitzen zu bändigen, bevor Logs die Platte füllen oder das System spürbar belasten.
• Die Kombination aus beiden Ansätzen verhindert, dass Logs entweder zu spät rotiert werden (bei plötzlichen Volumenanstiegen) oder zu oft rotiert werden (nur weil der Zeitplan greift, obwohl noch wenig Nutzdaten anfallen).

Größenoptionen im Überblick

• size SIZE: Rotiert, sobald die Logdatei eine definierte Größe überschreitet. SIZE kann in Megabyte (M), Kilobyte (K) oder Byte (B) angegeben werden.
• minsize SIZE: Die Rotation wird nur ausgelöst, wenn die Datei mindestens SIZE groß ist; in anderen Worten: selbst bei überschrittenem Zeitplan passiert keine Rotation, wenn das Log noch klein ist.
• maxsize SIZE: Rotation wird ausgelöst, sobald die Datei SIZE überschreitet, unabhängig davon, ob der geplante Zyklus bereits erreicht ist. Damit werden extreme Volumenabschnitte besser abgefangen.

Beispiele zur Orientierung:

• size 100M rotiert, sobald die Datei 100 MB erreicht.
• minsize 10M + daily bedeutet: Rotieren, wenn die Datei größer als 10 MB ist und der Tageszyklus erreicht ist.
• maxsize 500M erzwingt eine Rotation, sobald 500 MB erreicht sind, selbst wenn der tägliche Zyklus noch nicht abgeschlossen ist.

Lebensdauer, Versionierung und Aufbewahrung

• maxage setzt eine absolute Lebensdauer für rotierte Dateien. Nach Ablauf eines definierten Zeitraums werden alte Versionen gelöscht, unabhängig von ihrer Position im Zyklen‑Stack.
• rotate bestimmt, wie viele archivierte Versionen erhalten bleiben. Wer regelmäßig archiviert, möchte hier oft eine moderate Anzahl, um Speicherbedarf und Suchaufwand zu balancieren.
• In einer Praxis mit gemischten Anforderungen bedeutet das: zeitbasierte Rotationen liefern regelmäßige Backups, während maxsize/size‑basierte Trigger zusätzliche Versionen bei unerwarteten Lastspitzen erzeugen können.

Kaskadierende Regeln: Reihenfolge und Wechselwirkungen

• Ein Log kann sowohl täglich rotiert werden als auch durch Überschreitung einer Größe. Die Reihenfolge der Direktiven beeinflusst das Verhalten im konkreten Fall, da sie festlegt, welcher Trigger zuerst geprüft wird.
• Typischerweise gilt:
• Die zeitbasierte Rotation sorgt für regelmäßige Zyklen.
• Größenbasierte Trigger ergänzen diese Zyklen, um plötzliche Volumen zu handhaben.
• Praktisch bedeutet das: Definieren Sie eine klare Priorität, oft mit der zeitbasierenden Rotation als Hauptregel und Größe als ergänztem Trigger. So bleiben planbare Wartungsfenster erreichbar, während Spikes zuverlässig aufgefangen werden.
• Beachten Sie, dass die Rotationen nicht unendlich viele gleichzeitige Aktionen erzeugen sollten. In Konfigurationen ist es sinnvoll, entsprechende rotate‑ und maxage‑Werte so zu setzen, dass Archivierung übersichtlich bleibt und Konsistenz gewährleistet ist.

Praxisbeispiele: typische Muster in der Praxis

• Webserver‑Logs (nginx, Apache): Häufig daily, teilweise mit compress/delaycompress; zusätzlich Größentrigger wie size 50M oder maxsize 200M, je nach Traffic. So wird täglich eine Grundrotation sichergestellt, während starke Spitzen bei Logs trotzdem rasch behandelt werden.
• Größere Anwendungen: Setzen oft maxsize in Kombination mit rotate, um sicherzustellen, dass sehr große, unerwartete Logs nicht endlos anwachsen. minsize sorgt dafür, dass Rotationen nicht bei absolut kleinem Volumen stattfinden.
• Dienste mit hohem Schreibvolumen: Oft daily plus size‑Trigger, um sicherzustellen, dass bei einem plötzlichen Schub auch zeitnah rotiert wird, ohne den normalen Zyklus zu vernachlässigen.

Sinnvolle Praxis: Prioritäten setzen

• Die sinnvollste Praxis besteht in einer klaren Priorisierung:
• Erst die zeitbasierte Rotation als stabiler Kern, der regelmäßig Rotationen triggert.
• Dann eine größenbasierte Komponente, die Lastspitzen abfedert und zusätzliche Versionen erzeugt, wenn nötig.
• Zeitbasierte Rotation kann durch Size‑Trigger ergänzt werden, um unvorhergesehene Logs zuverlässig zu handhaben.
• Kombinieren Sie maxage und rotate, um eine definierte Historie zu behalten, während ältere Archive gemäß Lebensdauer entfernt werden.

Problemfall: Rekombination von zeit- und größenbasierten Triggern

• Wenn eine Logdatei gleichzeitig fast voll ist und der geplante Zyklus noch nicht erreicht wurde, greifen Size‑ und Time‑Trigger gemeinsam ein. Das sorgt für konsistente Rotationen, kann aber in manchen Konstellationen zu Doppel‑ oder Verpassten‑Zyklen führen.
• Lösungsvorschläge:
• Klare Priorisierung im Block der Direktiven (zeitbasierte Rotation oben).
• Einsatz von minsize, um Rotationen nur bei signifikantem Volumen zuzulassen.
• Prüfung, ob postrotate‑Skripte die neu geöffnete Logdatei ordnungsgemäß weiterführen, um inkonsistente Schreib‑Deskriptoren zu vermeiden.

Praktische Empfehlungen für die Implementierung

• Definieren Sie eine standardisierte Struktur pro Dienst:
• Hauptregel: daily/weekly oder monthly plus rotate‑N, compress/delaycompress.
• Größen‑Trigger: size oder maxsize in Kombination mit minsize, passend zum erwarteten Volumen.
• Lebensdauer: maxage zur automatischen Bereinigung alter Dateien.
• Nachbearbeitung: postrotate bzw. endscript, um Dienste sauber neu zu signalisieren.
• Testen Sie Konfigurationen im Dry‑Run‑Modus, bevor Sie sie in Produktion nehmen.
• Dokumentieren Sie die Priorisierung und die Begründung der Schwellenwerte, damit Wartungsteams konsistent arbeiten können.
• Überwachen Sie Speicherplatznutzung und Rotationstrigger in der Praxis, um frühzeitig Anpassungen vorzunehmen.

Zusammengefasst lässt sich sagen: Eine gut durchdachte Kombination aus zeit‑ und größenbasierter Rotation bietet die Flexibilität, um Lastspitzen gerecht zu verteilen, ohne die planbaren Wartungszyklen zu gefährden. Durch klare Priorisierung und sinnvolle Grenzwerte bleibt die Logarchivierung auch bei unvorhergesehenen Ereignissen zuverlässig handhabbar.

Postrotate/Prerotate-Skripte und Service-Neustart: sichere Öffnung von Logs nach Rotation

Nach der Rotation bleiben Dateien oft offen belegt oder Daemon‑Prozesse schreiben weiter in die alte Datei. Prerotate‑ und postrotate‑Blöcke ermöglichen gezielte Aktionen vor bzw. nach der Rotation, damit Daemons die neue Logdatei sauber weiternutzen. Gleichzeitiges Rotieren mehrerer Dateien muss nicht zu Mehrfach‑Operationen führen; sharedscripts koordiniert das. In der Praxis bedeuten sie, dass Skripte, die vor oder nach der Rotation laufen sollen, so koordiniert werden, dass sie zuverlässig funktionieren – unabhängig davon, wie viele Logs betroffen sind.

Prerotate- und Postrotate-Blöcke sinnvoll einsetzen

• Prerotate: Vor der Umbenennung der Logdatei Vorbereitungen treffen, z. B. prüfen, ob Dateien existieren oder Berechtigungen absichern.
• Postrotate: Nach der Rotation signalisieren Systeme üblicherweise Daemons, die Logs erneut zu öffnen bzw. zu schreiben.
• Sharedscripts: Diese Directive sorgt dafür, dass prerotate‑ bzw. postrotate‑Skripte nur einmal pro Rotation ausgeführt werden, egal wie viele Dateien betroffen sind. So werden Nebeneffekte vermieden, wenn mehrere Logdateien desselben Dienstes rotiert werden.

Signale und Reloads: Logs ordnungsgemäß weiterführen

• Nachrotation: Signale wie SIGHUP, SIGUSR1 oder gezielte Reload‑Events veranlassen Daemons, die Logs in der neuen Datei weiterzuschreiben.
• Typische Einsatzszenarien:
• Nginx: Master‑ oder Worker‑Prozesse müssen die neue Datei wiederöffnen, damit weiter in sie geschrieben wird.
• Apache: Je nach Variante genügt oft ein Reload bzw. ein Graceful‑Neustart.
• PHP‑FPM, MySQL, Redis u. a.: Je nach Variante genügt ein Reload, Neustart oder ein spezifisches Kill‑Signal.
• Grundidee: Der Dienst soll die neugeöffnete Logdatei übernehmen, ohne dass Logs zwischenzeitlich in der falschen Datei landen.

Postrotate-Beispiele: konkrete Befehle je Dienstvariante

• Nginx
• Beispielbefehl: nginx -s reopen
• Alternativ (Signal an Masterprozess): kill -USR1
• Hinweis: Der Pfad zur PID‑Datei variiert; prüfen Sie vor dem Signalisieren, dass er existiert.
• Apache
• Beispielbefehl: systemctl reload apache2 oder apachectl graceful
• Ziel ist ein Reload, damit sich der Dienst die neue Logdatei merkt.
• Generische Postrotate‑Beispiele
• Falls verfügbar, kill -USR1 $(cat /var/run/.pid) 2>/dev/null || true
• Oder: systemctl reload 2>/dev/null || true

Copytruncate vs. Postrotate

• Postrotate (empfohlen): Nachdem logrotate die Logdatei umbenannt hat, wird der Daemon über ein Signalisieren der Öffnung der Logdatei informiert. Dadurch verwendet die Anwendung künftig die neue, leere Datei.
• copytruncate: Kopiert die Originaldatei in den Archivnamen und kürzt das Original auf Null Bytes. Die Anwendung registriert den Wechsel oft nicht automatisch, was zu Zwischenzuständen führen kann.
• Risiko von copytruncate: Zwischenkopieren kann dazu führen, dass neue Logs in die Originaldatei erscheinen, während Archivdateien bereits gefüllt sind. Für Anwendungen mit sauberem Reload‑Mechanismus ist Postrotate die sicherere Lösung.
• Praktische Regel: Verwenden Sie copytruncate nur dann, wenn eine saubere Reload‑/Neueröffnung der Logdateien durch den Dienst nicht möglich ist oder kein entsprechendes Signalisieren unterstützt wird.

Praktische Regel: Vor der Rotation Skripte testen, nach der Rotation Dienste verlässlich neu laden oder neu starten

• Vor dem Deploy: Skripte in einer sicheren Testumgebung prüfen, ob sie bei allen betroffenen Diensten funktionieren.
• Nach der Rotation: Dienste zuverlässig neu laden oder neu starten, damit neue Logs korrekt geschrieben werden.
• Fehlerbehandlung: Fehlercodes abfangen und bei Problemen nicht stillschweigend fortfahren (|| true oder ähnliche Konstrukte sinnvoll, aber dokumentiert verwenden).
• Dokumentation: Rotationstransparenz herstellen, damit Wartungspersonen nachvollziehen können, welche Skripte wann laufen.

Endskript: Abschlusskapitel der Rotation und konsistente Logpfade sichern

• Endskript: Das Abschlusskapitel der Rotation sorgt dafür, dass alle nachfolgenden Schritte sauber abgeschlossen werden.
• Zweck: Mit dem klaren Abschluss der Rotation lassen sich Logs sicher prüfen, Pfade konsistent halten und Wiederholungseffekte vermeiden.
• Typische Endskript‑Aktionen: einfache Abschlussmeldungen ins Logsystem, Statusupdates oder das Triggern weiterer Monitoring‑Skripte.

Praktische Konfigurationen in der Praxis

• Beispielkonfiguration (Nginx‑Logs):
• /var/log/nginx/*.log {

daily missingok rotate 14 compress delaycompress sharedscripts postrotate if [ -f /run/nginx.pid ]; then kill -USR1 cat /run/nginx.pid ; fi endscript }

• Beispielkonfiguration (Apache‑Logs):
• /var/log/apache2/*.log {

weekly rotate 4 missingok notifempty create 0640 root adm sharedscripts postrotate systemctl reload apache2 endscript }

Fazit

• Prerotate‑ und postrotate‑Skripte geben Ihnen feine Kontrolle über den Ablauf der Logrotation.
• Sharedscripts verhindert Mehrfachausführungen pro Rotation und reduziert Nebeneffekte.
• Signale und Reloads nach der Rotation sichern, dass Daemons ordnungsgemäß in die neue Logdatei schreiben.
• copytruncate bietet eine Alternative, birgt jedoch Risiken; bevorzugen Sie postrotate mit korrektem Signalisieren.
• Vor der Einführung neuer Skripte gründlich testen; nach der Rotation verlässlich Dienste neu laden oder neu starten.
• Das endscript schließt die Rotation sauber ab und sorgt für konsistente Logpfade.

Testen, Debuggen und Best Practices in der Praxis

Die Praxis zeigt: Logrotation sicher betreiben bedeutet, Konfigurationen regelmäßig zu validieren, potenzielle Blockaden früh zu erkennen und klare Arbeitsabläufe für Tests zu definieren. Eine strukturierte Vorgehensweise minimiert unerwartete Ausfälle im Produktivbetrieb und erleichtert Wartung sowie Compliance. Im folgenden Abschnitt finden Sie praxisnahe Handgriffe und Checklisten, die sich direkt in realen Serverlandschaften anwenden lassen.

Trockenlauf und Debug-Modus

• Trockenlauf‑Sicherheit: Der Dry‑Run (Trockenlauf) prüft Rotationen, ohne Dateien zu verschieben oder zu verändern. Dadurch validieren Sie Konfigurationen, bevor Produktionsdateien betroffen sind.
• Sicherheitsabbildung durch Debug‑Modus: Der Debug‑Modus zeigt, was passieren würde, ohne Dateien tatsächlich zu rotieren; so erkennen Sie früh potenzielle Falschkonfigurationen.
• Verlässliche Tests mit expliziten Flags: Der Debug‑Modus lässt sich mit zusätzlichen Optionen versehen, um Umstände wie fehlende Dateien oder spezielle Verzeichnisse gezielt zu simulieren.
• Praktische Anwendungsfälle: Verwenden Sie logrotate -d /etc/logrotate.conf für den Überblick, logrotate -d -f /etc/logrotate.conf für einen gezielten Forced‑Dry‑Run und logrotate -v /etc/logrotate.conf für ausführliche Meldungen während einer Rotation.

Statusdatei beobachten

• Statusdatei im Blick behalten: Die zentrale Statusdatei befindet sich typischerweise unter /var/lib/logrotate/status. Sie dokumentiert, wann jede Log‑Datei zuletzt rotiert wurde.
• - Manuelles Resetting bei Beschädigungen: Falls die Statusdatei beschädigt oder unlesbar wird, legen Sie sie erneut an oder setzen Sie sie zurück; danach läuft logrotate wieder wie gewohnt.
• Auffälligkeiten interpretieren: In der Statusdatei stehen pro Logdatei Zeitstempel; Abweichungen oder fehlende Zeitangaben deuten auf Konfigurations‑ oder Laufzeitprobleme hin.
• Operationaler Routine‑Tipp: Führen Sie regelmäßig einen Blick in die Statusdatei durch – idealerweise gekoppelt an Monitoring‑ oder CI‑Checklisten – und dokumentieren Sie Abweichungen.
• Schnelle Validierung: Nach einer Konfigurationsänderung prüfen Sie per Trockenlauf, ob Einträge wie erwartet erscheinen und betroffene Dateien korrekt berücksichtigt werden.

Sicherheits- und Dateirechte

• Verzeichnisberechtigungen beachten: Fehlende oder zu offene Berechtigungen im Zielverzeichnis oder in den Dateieigentümern können Rotationen blockieren.
• Taboo‑Dateien kennen: Dateien mit Taboo‑Erweiterungen (z. B. .rpmsave, .rpmorig, .dpkg‑old, .dpkg‑dist etc.) dürfen nicht rotiert werden; sie werden von logrotate standardmäßig ignoriert.
• Richtige Eigentümer und Modi sicherstellen: Neue Logdateien sollten die richtigen Berechtigungen (z. B. 0640) sowie Eigentümer/Gruppe erhalten; andernfalls kann der Logwriter Schreibzugriffe verlieren.
• Praktische Schritte: Prüfen Sie vor dem ersten Produktivlauf die Berechtigungen des Logverzeichnisses (z. B. Eigentümer) und setzen Sie restriktive, aber notwendige Zugriffe (z. B. 755 für Verzeichnisse, 640/644 für Dateien).
• Fehlerursachen minimieren: Wenn Rotationen scheitern, prüfen Sie zunächst, ob andere Prozesse Aktivitäten in den Dateien blockieren oder Verzeichnisse vor Schreibzugriffen durch andere Nutzer geschützt sind.

SELinux-Kontexte und File-Context-Reclear

• Blockaden durch SELinux erkennen: SELinux‑Kontexte können Rotationen blockieren, insbesondere in Umgebungen mit strengem Policy‑Set.
• restorecon als Rettungsanker: Der Befehl restorecon -v kann Blockaden lösen, indem er Dateikontexte neu setzt; damit werden Berechtigungen und Sicherheitskontexte konsistent hergestellt.
• Getrennte Tests bevorzugen: Führen Sie Tests in einer stabilen Testumgebung durch, bevor Sie SELinux‑bezogene Änderungen in der Produktion anwenden.
• Praxis‑Tipp: Nach Anpassungen an Kontexten oder Policy‑Durchläufen führen Sie einen kontrollierten Testlauf durch, um Produktionsrisiken zu vermeiden.

Cron-Integrationen prüfen

• Cron‑Deployment verstehen: Viele Systeme führen logrotate über den täglichen Cron‑Job aus; daneben kommen systemd‑Timer‑Lösungen zum Einsatz, die Rotationen zeitnah auslösen.
• Dienstlaufprüfungen: Stellen Sie sicher, dass der Cron‑Dienst läuft bzw. der Timer aktiv ist; eine fehlerhafte Cron‑Umgebung blockiert Rotationen.
• Typische Prüfschritte: Prüfen Sie den Aufrufpfad (z. B. /etc/cron.daily/logrotate) sowie die systemd‑Timer‑Konfiguration, und verifizieren Sie, dass keine Fehlermeldungen in den Cron‑Logs auftreten.
• Robuste Planung: Für produktive Deployments empfiehlt sich eine Kombination aus Cron/Timer und Monitoring, um Rotationen zuverlässig zeitnah zu erkennen.

Fehlerquellen analysieren

• Fehlende Dateien (missingok): Wenn Dateien fehlen, läuft logrotate fehlerfrei weiter; ohne missingok könnte ein Fehler auftreten.
• Leere Dateien (notifempty): Leere Dateien werden oft ignoriert; beachten Sie, dass Ausnahmen möglich sind, wenn Sie dies explizit wünschen.
• Postrotate‑Befehle prüfen: Falsche postrotate‑Befehle oder fehlerhafte Pfade führen dazu, dass der automatische Neustart oder Reload des Dienstes scheitert.
• Race‑Conditions vermeiden: Nutzen Sie copytruncate‑ versus create/postrotate‑Skript‑Ansätze; testen Sie beide Muster separat, um Generationsfehler zu vermeiden.
• Diagnose‑Routine: Bei Problemen loggen Sie die Rotation zunächst im verbose‑Modus, prüfen Sie die relevanten Prozesssignale (z. B. SIGUSR1, HUP) und validieren Sie die Script‑Entrypoints.

Dokumentation der Konfiguration und regelmäßige Validierung sichern Wartbarkeit

• Konfigurationsdokumentation pflegen: Halten Sie zentrale Richtlinien, Overrides und dienstspezifische Regeln in einer gut auffindbaren Dokumentation fest.
• Änderungen nachvollziehen: Führen Sie eine Änderungsprotokollierung zu logrotate‑Konfigurationen (Changelog, Kommentarzeilen in den Dateien) ein.
• Regelmäßige Validierung etablieren: Planen Sie regelmäßige Trockenläufe und Rotationen in Testumgebungen; automatisieren Sie zumindest partielle Checks, um unbemerkte Fehlkonfigurationen zu verhindern.
• Wartbarkeit steigern: Erstellen Sie eine kompakte Checkliste pro Dienst (Pfad der Logs, rotate‑Anzahl, create‑Option, postrotate‑Befehl) und verankern Sie diese in der Dokumentation.
• Schulungsaspekt: Neue Teammitglieder sollten eine kurze Einweisung in die Test‑ und Debug‑Prozesse erhalten, damit Deployment‑Pipelines nicht durch Unbekanntes ins Stocken geraten.

Beständig angewendet, führt diese Praxis zu stabiler Rotation, verlässlicher Archivierung und einer insgesamt besseren Wartbarkeit der Log‑Infrastruktur. Eine klare Trennung von Test‑ und Produktionsläufen, zusammen mit einer gut dokumentierten Konfiguration und regelmäßigen Validierungen, senkt das Risiko erheblich und erleichtert Audits sowie Incident‑Reaktionen.

Fazit

Am Ende zeigt sich, dass der Schlüssel zu stabiler Logrotation in der klugen Kombination aus globalen Defaults und dienstspezifischen Overrides liegt. Durch dateext/dateformat lassen sich Archive transparent nachverfolgen, sharedscripts verhindern Mehrfachausführungen, und die Entscheidung zwischen create und copytruncate entscheidet über Race‑Conditions. Prerotate‑ und postrotate‑Blöcke ermöglichen es, Daemons sauber neu zu öffnen oder zu signalisieren, sodass neue Logs unverzüglich anfallen. Die gleichzeitige Berücksichtigung zeit‑ und größenbasierter Trigger sorgt dafür, dass Lastspitzen abgefedert werden, ohne planbare Zyklen zu gefährden. Das Ergebnis ist eine nachvollziehbare Historie, ein kontrollierter Speicherverbrauch und eine robuste Betriebsbereitschaft.

Um dieses Ziel dauerhaft zu erreichen, priorisieren Sie sorgfältige Tests im Dry‑Run‑Modus, dokumentieren Sie Abhängigkeiten und Warnungen, prüfen Sie Berechtigungen, SELinux‑Kontexte und Cron‑/Timer‑Integrationen, und halten Sie Konfigurationen zentral nachvollziehbar fest. Eine regelmäßige Validierung – etwa durch strukturierte Checklisten, Monitoring der Statusdatei und Audits der Archivierung – steigert Wartbarkeit und Sicherheit. Mit dieser disziplinierten Vorgehensweise lassen sich Logs effizient handhaben, Speicherressourcen schonen und Vorfälle schneller nachvollziehen, sodass der Betrieb auch unter Last stabil bleibt.