HMIP Geräte "verschwinden"

[grazcrew]

Ich habe das Problem, dass nach 3-4 Tagen meine HM-IP Geräte nicht mehr da sind. Zudem sind die Diagramme nicht mehr da.
Das ist ziemlich dumm, weil ich den MP3-IP Funkgong habe und wir nun dann keine Türglöcke haben . Leider merke ich den "absturz" nicht, was wirklich schlecht ist.

Nach einen Reboot läuft es dann wieder perfekt, bis die HM-IP Sachen weg sind.

Das ist das CUX-Kernellog:

<3>[474401.354403] Out of memory: Kill process 836 (java) score 86 or sacrifice child
<3>[474401.354604] Killed process 836 (java) total-vm:280200kB, anon-rss:87936kB, file-rss:0kB, shmem-rss:76kB
<6>[474401.394275] oom_reaper: reaped process 836 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:32kB
<6>[474401.397841] eq3loop: eq3loop_close_slave() mmd_hmip

Was könnte das sein?

[jmaus]

<3>[474401.354403] Out of memory: Kill process 836 (java) score 86 or sacrifice child
<3>[474401.354604] Killed process 836 (java) total-vm:280200kB, anon-rss:87936kB, file-rss:0kB, shmem-rss:76kB
<6>[474401.394275] oom_reaper: reaped process 836 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:32kB
<6>[474401.397841] eq3loop: eq3loop_close_slave() mmd_hmip

Was könnte das sein?

Na das was da steht: "Out of memory".

Das Linux system killt deinen HmIPServer Prozess einfach hart weil anscheinend das System keinen Arbeitsspeicher mehr zur Verfügung hat. Welchen RaspberryPi/Tinkerboard setzt du denn da ein und wie steht es mit der generellen Speicherauslastung? Was für andere Dinge betreibst du da noch auf dem System? RedMatic oder ähnliches?

[grazcrew]

Der "Crash" liegt im genau den gleichen Zeitraum, wo das Backup auf USB erzeugt wird. Könnte es ggf. daran liegen? Es läuft ja einige Tage ohne Probleme und dann ist plötzlich schluss ...

Genau, RedMatic hatte ich mal vor einiger Zeit installiert. Ich habe es nun deinstalliert. Könnte es ggf. daran liegen?

Ich nutze den aktuellen Raspi 3 B+

[jmaus]

Der "Crash" liegt im genau den gleichen Zeitraum, wo das Backup auf USB erzeugt wird. Könnte es ggf. daran liegen? Es läuft ja einige Tage ohne Probleme und dann ist plötzlich schluss ...

Nein, denke nicht das das Backup den Arbeitsspeicher auffrisst, ausser natürlich du lässt das an den falschen Ort backupen, z.B. eben in den Arbeitsspeicher (/tmp, /var, etc.) Aber mit den Standardeinstellungen sollte das direkt das Backup auf dem USB Stick erzeugen und mehr nicht.

Genau, RedMatic hatte ich mal vor einiger Zeit installiert. Ich habe es nun deinstalliert. Könnte es ggf. daran liegen?

Was heisst "nun"? Hast du es frisch deinstalliert und ist seit dem deinstallieren wieder ein solcher Absturz passiert? Du müsstest eben mal wenn das wieder passiert direkt auf die CCU/RaspberryMatic gehen und mit "top" bzw. "free" Kommando mal die Speicherauslastung anschauen und rausfinden warum der Arbeitsspeicher zu neige geht. Der HmIPServer Prozess Ansicht verbraucht zwar rund 200MB aber das alleine ist nicht kritisch. Ich vermute irgendetwas anderes bei dir Frist den Arbeitsspeicher auf und dann fühlt sich das Linux System genötigt Platz zu schaffen und killt dann eben mitunter den HmIPServer.

[grazcrew]

Also, ich hatte eigentlich nie ein Problem mit dem System. Nachdem ich das RedMatic (vor einigen Wochen) installiert habe, hatte ich diesen "Crash" mehrmals. HEUTE habe ich RedMatic deinstalliert (nach dem Crash) und ein Reboot gemacht.

Ich werde das nun beobachten. Ich hatte das RedMatic übrigens nie benutzt. Ich suchte nach eine Möglichkeit (schöne) Grafix für NEO zu erzeugen, auf mein 12" PAD. CCU-Historian gefällt mir nicht so gut dafür ....

[jmaus]

Ich werde das nun beobachten. Ich hatte das RedMatic übrigens nie benutzt. Ich suchte nach eine Möglichkeit (schöne) Grafix für NEO zu erzeugen, auf mein 12" PAD. CCU-Historian gefällt mir nicht so gut dafür ....

Wie gesagt, beobachte eben die Speicherauslastung auf dem System mit "top" und "free" um rauszufinden welche Prozesse wieviel Speicher verbrauchen. Und wenn du CCU-Historian auch noch direkt auf RaspberryMatic betreibst kann es zusätzlich mit RedMatic schon eng werden, auch wenn du dann noch den Mediola NEO Server z.B. betreibst. Am Ende hat ein RaspberryPi eben "nur" 1GB und das reicht mit vielen Addon dann auch irgendwann nicht mehr und du solltest entweder darüber nachdenken Addons zu deinstallieren bzw. den Speicherverbrauch zu überwachen oder im Zweifel ein "ASUS Tinkerboard S" statt eines RaspberryPi nutzen, denn das hat 2GB RAM und damit schon noch mehr Luft. IMHO ist das Tinkerboard ohnehin auch aus anderen Gründen die bessere Wahl für eine RaspberryMatic CCU in der man mehrere größere CCU Addons nutzen will...

[Familienvater]

Hi,

vor allem, wie verhält es sich mit der Datenbank vom CCU-Historian, wird die beim Backup ausgelassen, oder kann eine mit der Zeit wachsende Datenbank bei "jedem" das TempFs beim Backup-Bauen sprengen?

Der Familienvater

[grazcrew]

CCU-Historian läuft bei mir auf einen Windows PC.

[jmaus]

vor allem, wie verhält es sich mit der Datenbank vom CCU-Historian, wird die beim Backup ausgelassen, oder kann eine mit der Zeit wachsende Datenbank bei "jedem" das TempFs beim Backup-Bauen sprengen?

Bei RaspberryMatic wird das Backup (egal ob via WebUI oder via cron-basiertem automatischen Backup) nicht im tempfs erstellt sondern immer direkt auf dem jeweiligen Target Datenträger.

[hobbyquaker]

Der "Crash" liegt im genau den gleichen Zeitraum, wo das Backup auf USB erzeugt wird. Könnte es ggf. daran liegen? Es läuft ja einige Tage ohne Probleme und dann ist plötzlich schluss ...

Genau, RedMatic hatte ich mal vor einiger Zeit installiert. Ich habe es nun deinstalliert. Könnte es ggf. daran liegen?

RedMatic braucht viel RAM, daher liegt es nahe dass es die Ursache sein kann. Daran kann ich leider auch nichts drehen. Wegen dem Backup: da bestätige ich Jens, auf RaspberryMatic ist das völlig harmlos, grade mal geschaut, tar und gzip gönnen sich während des Komprimierens zusammen nicht mal 6MB VSZ, beim Runterladen hat der Lighttpd minimal (paar kB) mehr Speicher angefordert. Außerdem belegt ein aktuelles RedMatic auf RaspberryMatic nicht mehr soooo viel Backup-Space seit ich die .nobackup Tags für verzichtbare Verzeichnisse verwende.
Völlig anders sieht das allerdings auf einer CCU3 aus, da wird das immer mehr zum Problem. eQ-3 hat leider noch nicht den Parameter übernommen um das .nobackup Tag zu unterstützen und das Backup .tar.gz wird dazu auch noch im tmpfs (also im RAM) erzeugt und RedMatic belegt darin dann rund 70MB. Aber anderes Thema, auf RaspberryMatic is das ja zum Glück kein Problem.

Wovon ich aber dringend abrate (auch RaspberryMatic Nutzern) ist Mediola und RedMatic auf einem System mit 1GB RAM parallel zu betreiben. Beides Node.js, beides Speicherintensiv, da sollte man sich dann für eins von beidem entscheiden oder ein System mit 2GB RAM nutzen.

Um RedMatic auf die Finger zu schauen was sein Speicherbedarf angeht zeigt es übrigens auf der Systemsteuerungsseite immer seine aktuelle RAM-Nutzung an, aktuell bei mir mit recht vielen Nodes und 2 Bridges mit > 100 HomeKit Accessories sieht das so aus:

230MB/130MB sind natürlich nicht wenig, aber auf meinem System noch unkritisch.