adminandClaude Opus 5
1f1700391d
wecker.py hat genau das getan, was der AutoAction-Runner ohnehin kann - nur mit allem doppelt: eigener Datenbank alarm, eigenem Feiertags- und Ferienkalender neben calendar_days, eigenem UDP-Log auf Port 13377, eigener Endlosschleife und einem Startskript samt naechtlichem Neustart um drei. Punkt fuer Punkt hatte der Runner die bessere Fassung schon: die Zeit als Bedingung "um 05:50" mit Nachholfenster statt eines Vergleichs im 20-Sekunden-Takt, weekdays als Bitmaske statt sieben Spalten, on_holiday/on_vacation gegen calendar_days statt gegen einen zweiten Kalender, die steigende Flanke statt einer wecked-Spalte, und den Versand mit einem Faden je Geraet statt fuenf HTTP-Versuchen im Abstand von vier Sekunden. Umgezogen ist die eine Weckzeit, die scharf war: 05:50, Mo-Fr, nicht in den Ferien, nicht an Feiertagen, WLED-Preset 5 auf MenasHimmel. Die drei anderen Zeilen in alarmtime standen auf onoff = -1. wecker_zu_automatik.sql legt die Automatik an und beschreibt im Kopf, wie dasselbe im Dashboard von Hand geht. Die Datenbank alarm und der Abschnitt [alarm] in der config.ini bleiben vorerst stehen - sie liest nur niemand mehr. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
1.9 KiB
Plaintext
44 lines
1.9 KiB
Plaintext
# 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
|
|
}
|