HMIP Geräte "verschwinden"

[jmaus]

Danke Sebastian für das Klarstellen.
Ich werde mal überlegen ein Art Watchdog in einer der nächsten RaspberryMatic Versionen zu integrieren der dann in regelmäßigen Abständen wichtige Systemparameter (unter anderem auch den RAM Verbrauch) monitored und dann ggf. eine Homematic interne Alarmmwldung generiert wenn der RAM knapp wird. Vielleicht werde ich das dann auch noch hier/da um z.b. ein Monitoring der wichtigstenen Homematic Dienste (rfd, hmipserver, etc) erweitern wie das mein hm-watchdog addon auch bereits tut...

[hobbyquaker]

Noch ne Idee zu dem Thema: Vielleicht sollte man einfach den OOM Score beeinflussen und dafür sorgen dass eventuell speicherfressende Addon-Prozesse vor dem hmipserver abgeschossen werden. Holzhammer wäre den OOM Kill für den hmipserver komplett zu deaktivieren, sauberer wäre es aber denke ich den Score der Addon-Prozesse runterzusetzen. Hier ist erläutert wie der Score berechnet wird: https://linux-mm.org/OOM_Killer. Ich überleg mal ob ich da was in RedMatic einbau damit es sich selbst "unwichtiger" macht Habs mal auf die Todo genommen: https://github.com/HM-RedMatic/RedMatic/issues/142

[jmaus]

Das ist in der Tat ein guter Hinweis! Danke dir Sebastian. Es scheint hier sogar ein recht einfachen weg über das procfs zu geben die oom scores von prozessen zu beeinflussen. Siehe https://www.oracle.com/technetwork/arti ... 11807.html

Denke so könnte ich einfach in den Startup skripten der wichtigsten homematic dienste den oom score entsprechend anpassen das diese wirklich nur als allerletzte möglichkeit gekillt werden. Kannst du dazu im RaspberryMatic GitHub ein entsprechendes Enhancement Ticket aufmachen, sitze gerade im Zug nach HH

[hobbyquaker]

Ich denke die Entscheidung wird immer zwischen hmipserver und eventuellen großen Addons fallen. Die RAM-Nutzung geht als gewichtigster Faktor in den Score ein, und außer hmipserver, CCU-Historian, Node-RED und Mediola gibts ja nichts was Java/Nodejs like RAM verbrät. hier mal ein paar Beispielscores:

hmipserver: 71
node-red: 106
lighttpd-ange: 0
rfd: 12

[jmaus]

Trotzdem wurde anscheinend in diesem falle der HmIPServer statt etwas anderem gekillt. Denke kann nicht schaden die oom_adj werte aller hoemmatic kritischen dienste (inkl ReGaHss) entsprechend anzupassen damit diese in jedem Falle am leben bleiben.

[hobbyquaker]

Ja, der hat normalerweise ein höheren Score als RedMatic weil er sich noch mehr RAM gönnt. In meinem Beispiel ist er glaube ich nur deswegen niedriger weil die Uptime von RedMatic kurz ist, hab das vorher neugestartet und das senkt die "badness" Ich werd mal den Score von RedMatic 50 erhöhen, dann sollte er immer höher sein als der vom hmipserver. Ich denk ja auch noch mit an die CCU3 - und die wird Deine Anpassung ja erst "irgendwann" bekommen

[hobbyquaker]

Der "Crash" liegt im genau den gleichen Zeitraum, wo das Backup auf USB erzeugt wird. Könnte es ggf. daran liegen?

Noch eine Frage dazu. Erzeugst Du das Backup mit dem CUxD Tool extra/ccu_backup?

[grazcrew]

Der "Crash" liegt im genau den gleichen Zeitraum, wo das Backup auf USB erzeugt wird. Könnte es ggf. daran liegen?

Noch eine Frage dazu. Erzeugst Du das Backup mit dem CUxD Tool extra/ccu_backup?

Ich hatte zwei Backups gemacht, eines um 0:00 Uhr mit dem Script aus dem RaspberryMatic (CRON) und eines um 02:30 aus dem CUXd per Programm (scriptaufruf). Das läuft aber schon sehr lange bei mir so, ohne Probleme. Ich habe das 2. um 02:30 nun abgeschaltet.

Was ist eigentlich mit dem "Mediola" Server gemeint? Is dass dr NEO -Server, der steht bei mir -> "Status: offline"

[hobbyquaker]

Ich hatte zwei Backups gemacht, eines um 0:00 Uhr mit dem Script aus dem RaspberryMatic (CRON) und eines um 02:30 aus dem CUXd per Programm (scriptaufruf).

Grade nachgeschaut, das CUxD Backup Script unterstützt das .nobackup flag nicht und erzeugt erst ein .tar.gz von /usr/local (wo auch die Addons enthalten sind) in /tmp und dann erzeugt es (in default Konfiguration) das "finale" .tar in /var/tmp (was auch ein tmpfs ist). Braucht also - soweit ich das richtig verstehe - mehr als doppelt soviel RAM als das Backup groß ist.
Ich denke man kann also davon ausgehen dass das durch RedMatic stark vergrößerte Backup in Kombination mit dem CUxD Backup Script die Ursache des "Out of Memory" war.

Edit: Ergänzung - Noch geschaut wie eQ-3 das Backup erzeugt - die geben das "finale" tar direkt als Download durch - das benötigt also im Gegensatz zu dem CUxD Script nicht den doppelten Platz im RAM.