# Rotation der Logdateien des SolarManagers.
#
# Aufgerufen wird das ueber logs_rotieren.sh, einmal taeglich aus dem
# Aufgabenplaner. Nicht in /etc/logrotate.d abgelegt: das ist DSM-Gebiet und
# waere beim naechsten Systemupdate weg. Hier steht es neben den Prozessen,
# zu denen es gehoert, und liegt im selben Repository.
#
# copytruncate ist der Kern der Sache. Die Prozesse laufen monatelang durch
# und halten ihre Logdatei offen; niemand will sie fuer eine Rotation neu
# starten. Also wird der Inhalt weggeschrieben und die Datei geleert, statt
# sie umzubenennen - der Prozess merkt nichts davon. Voraussetzung ist, dass
# die Startskripte mit ">>" umleiten und nicht mit "&>", sonst schreibt der
# Prozess nach dem Leeren an seiner alten Stelle weiter und die Datei
# bekommt ein Loch aus Nullbytes. Genau deshalb wurde das dort umgestellt.
#
# Der Preis von copytruncate sind die Zeilen, die zwischen Kopieren und
# Leeren hereinkommen - die gehen verloren. Bei einem Betriebslog ist das
# der guenstigere Handel.

/volume1/homes/wagner/SolarManager/solarOutput.log
/volume1/homes/wagner/SolarManager/autoActions.log
/volume1/homes/wagner/SolarManager/rainOutput.log
/volume1/homes/wagner/SolarManager/wattpilotshell.log
/volume1/homes/wagner/SolarManager/wsMQTTbridge.log
{
    monthly
    # Zwei Wochen zurueck. Weiter zurueck hat noch nie jemand gesucht, und
    # was aelter ist, steht ohnehin als Messwert in der Datenbank.
    rotate 14
    # Zusaetzlich zur Tagesgrenze: was ueber 20 MB geht, wird sofort
    # rotiert. Sonst koennte ein Prozess, der in eine Fehlerschleife
    # geraet, an einem einzigen Tag das Volume fuellen.
    maxsize 10M
    compress
    # Eine leere Datei zu rotieren bringt nichts ausser vierzehn leeren
    # Archiven, und mehrere dieser Prozesse melden an den meisten Tagen
    # gar nichts.
    notifempty
    # Fehlt eine Datei, ist das kein Fehler: nicht jeder Prozess laeuft
    # auf jedem System.
    missingok
    copytruncate
}