Logrotation: die Dateien wachsen nicht mehr unbegrenzt

wattpilotshell.log hatte 329 MB erreicht - die wattpilotshell meldet
seit Monaten im Sekundentakt denselben Verbindungsfehler, und rotiert
wurde nie. logs_rotieren.sh mit logrotate.conf raeumt das jetzt taeglich
auf: vierzehn Staende, alles ueber 20 MB sofort, damit ein Prozess in
einer Fehlerschleife nicht an einem Tag das Volume fuellt. Der erste Lauf
hat aus den 329 MB 61 KB gemacht, verloren ist nichts.

Nicht in /etc/logrotate.d abgelegt - das ist DSM-Gebiet und beim
naechsten Systemupdate weg. Der Zustand kommt aus einer eigenen Datei
statt aus /var/lib/logrotate, wo der von DSM liegt.

Die Startskripte leiten dafuer mit ">>" um statt mit "&>". Die Prozesse
laufen monatelang durch und sollen fuer eine Rotation nicht neu starten
muessen, deshalb copytruncate - der Inhalt wird weggeschrieben und die
Datei geleert, waehrend sie offen bleibt. Ohne Anhaengemodus schriebe der
Prozess danach an seiner alten Stelle weiter und die Datei bekaeme vorn
ein Loch aus Nullbytes.

Nebenbei behoben: startWecker.sh leerte seine Logdatei bei jedem Start,
und gestartet wird der Wecker jede Nacht um drei. Was er am Vortag
gemeldet hatte, war morgens nicht mehr nachzulesen.

Die Skripte bekommen ausserdem ihr Ausfuehrungsrecht in den Index - ueber
die Windows-Freigabe sieht Git keine Unix-Rechte, ein frischer Checkout
haette sie nicht starten koennen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

logrotate.conf

@@ -0,0 +1,42 @@
+# 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/wattpilotshell.log
+/volume1/homes/wagner/SolarManager/wsMQTTbridge.log
+/volume1/homes/wagner/SolarManager/wecker.log
+{
+    daily
+    # 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 20M
+    compress
+    # Eine leere Datei zu rotieren bringt nichts ausser vierzehn leeren
+    # Archiven - der Wecker meldet an den meisten Tagen gar nichts.
+    notifempty
+    # Fehlt eine Datei, ist das kein Fehler: nicht jeder Prozess laeuft
+    # auf jedem System.
+    missingok
+    copytruncate
+}