# Logrotate Deep Dive: Ordnung in der Datenflut

TL;DR / Management Summary Nichts bringt einen Server schneller zum Stillstand als eine volle Partition durch unkontrolliert wachsende Logdateien. logrotate ist der Standard-Dienst, um Logs periodisch zu archivieren, zu komprimieren und nach einer bestimmten Zeit zu löschen. Ein Senior Admin nutzt logrotate, um sicherzustellen, dass das System auch bei massiven Fehlermeldungen stabil bleibt, und triggert nach der Rotation automatisierte Re-Inits von Diensten (postrotate).

# 1. Einführung & Architektur

Der Zyklus der Daten.

Logrotate ist kein Dämon, sondern wird meist einmal täglich via Cron oder Systemd-Timer gestartet. Es liest die Konfiguration und prüft für jede Datei, ob ein Rotations-Kriterium (Zeit oder Größe) erreicht ist.

# Der Rotations-Workflow (Mermaid)

graph LR
    A[Active Log: app.log] -->|Threshold reached| B[Rotation: Rename]
    B --> C[Archived: app.log.1]
    C -->|Next Cycle| D[Compressed: app.log.2.gz]
    D -->|Retention limit| E[Deleted: Clear Space]
    subgraph "Triggers"
        F[Time: daily / weekly]
        G[Size: > 100MB]
    end
    F/G --> B

# 2. Die Konfiguration

Regeln für die Hygiene.

Die globale Konfig liegt in /etc/logrotate.conf. Applikations-spezifische Regeln legen wir unter /etc/logrotate.d/ ab.

# Beispiel: Ein sicheres Setup für Nginx

Datei: /etc/logrotate.d/nginx

/var/log/nginx/*.log {
    daily
    rotate 14
    missingok
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 `cat /var/run/nginx.pid`
        fi
    endscript
}

# 3. Die wichtigsten Parameter (Enterprise)

Präzision statt Zufall.

• compress: Archivierte Logs werden sofort mit gzip verkleinert.
• delaycompress: Das Komprimieren erfolgt erst beim nächsten Zyklus (hilfreich, wenn Prozesse die alte Log-Datei noch kurzzeitig offen halten).
• copytruncate: Für Applikationen, die das Logfile nicht schließen können. Es kopiert den Inhalt und leert dann die Originaldatei (Vorsicht: Minimaler Datenverlust möglich!).
• create: Erstellt sofort eine neue, leere Datei mit spezifischen Rechten (Artikel 283).

# 4. Day-2 Operations: Manuelle Ausführung

Eingreifen, wenn es brennt.

Wenn eine Partition zu 99% voll ist, warten wir nicht auf den nächsten Cronjob.

# Erzwingt die Rotation aller konfigurierten Logs sofort
sudo logrotate -f /etc/logrotate.conf

# Nur eine spezifische Konfig testen (Debug-Modus)
sudo logrotate -d /etc/logrotate.d/myapp

# 5. Troubleshooting & “War Stories”

Wenn die Rotation das System bricht.

# Story 1: “Der hängende Dienst nach Rotation”

Symptom: Die Logdatei wird rotiert, ist danach aber leer, obwohl die Applikation weiterläuft. Ursache: Die Applikation schreibt weiterhin in den alten File-Descriptor (der nun app.log.1 heißt). Sie hat nicht bemerkt, dass die Datei umbenannt wurde. Lösung: Nutzen Sie postrotate, um dem Dienst ein Signal (SIGHUP oder USR1) zu senden, oder nutzen Sie copytruncate.

# Story 2: “Die Permission-Denied Falle”

Symptom: Logs werden rotiert, aber die neue Datei hat die Rechte 600 für root. Der Webserver kann nicht mehr reinschreiben und stürzt ab. Ursache: Fehlende create Anweisung in der logrotate-Konfig. Lösung: Definieren Sie immer explizit User und Gruppe: create 0640 myuser mygroup.

# 6. Fazit & Empfehlung

• Standard: Nutzen Sie für jeden Dienst, den Sie manuell installieren, eine eigene logrotate-Datei.
• Platz: Überwachen Sie /var/log mit einer eigenen Partition (Artikel 019), damit volle Logs niemals das Root-Dateisystem blockieren.
• Wahl: Nutzen Sie daily für High-Traffic Dienste und size 50M für Dienste, die unvorhersehbare Mengen an Daten produzieren.

# Anhang: Cheatsheet