fhem mit piVCCU3 ist unbedienbar

[Zeitisen]

Ich habe vor einer Woche einen Pi 3B mit Bullseye komplett neu aufgesetzt.

Nun kommt es circa alle zwei Tage vor, dass fhem unbedienbar wird, obwohl es im Hintergrund weiterzulaufen scheint.

Auch eine Verbindung mit ssh ist nicht mehr möglich. Es hilft nur noch Stecker ziehen.

Eine Untersuchung des kernel.log bringt folgenden Hinweis:

Code Auswählen Erweitern

Aug  6 01:17:22 datalogger2 kernel: [237062.176273] loop0: detected capacity change from 0 to 524288
Aug  6 01:17:22 datalogger2 kernel: [237062.232446]  loop0:
Aug  6 10:16:09 datalogger2 kernel: [269365.973973] eq3loop: eq3loop_write_master() retrun error:
Aug  6 10:17:26 datalogger2 kernel: [269372.723044] eq3loop: eq3loop_write_master() mmd_hmip: not enought space in the buffers. free space = 1, required space = 12
Aug  6 10:18:04 datalogger2 kernel: [269425.910485] eq3loop: eq3loop_write_master() retrun error:

Speicher ist aber noch genug vorhanden, zumindest war er bis vor dem Aufhängen ok:

Code Auswählen Erweitern

top - 17:48:41 up  7:28,  3 users,  load average: 0,03, 0,07, 0,12
Tasks: 220 total,  1 running, 219 sleeping,  0 stopped,  0 zombie
%CPU(s):  0,4 us,  0,6 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:    922,0 total,    142,2 free,    641,3 used,    138,4 buff/cache
MiB Swap:    100,0 total,      0,1 free,    99,9 used.    216,0 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM    ZEIT+ BEFEHL                       
 6555 fhem      20  0  221008 149716  4676 S  0,7  15,9  19:32.72 perl                         
13093 fhem      20  0  221008 148244  3204 S  0,0  15,7  0:00.83 perl                         
 6751 fhem      20  0  216372 143348  2660 S  0,0  15,2  1:23.42 perl                         
 6752 fhem      20  0  213676 140600  2680 S  0,0  14,9  0:13.46 perl                         
 6754 fhem      20  0  213684 139796  2012 S  0,3  14,8  0:12.55 perl                         
 2413 root      20  0  278008 103084  3268 S  0,3  10,9  7:22.89 java                         
 2663 root      10 -10  135620  47692  5644 S  0,0  5,1  0:13.55 node   

Kann man piVCCU3 mehr speicher geben?
Gibt es sonst noch irgendwelche Möglichkeiten?

[juemuc]

Also bei mir läuft piVCCU3 auf einem Pi3B mit FHEM seit Jahren absolut stabil. Alle Komponenten sind aktuell. Ich habe alles nach "Vorgabe" installiert.
Warum hast Du nicht auch das "Betriebssysten" auf "Bullsey" aktuallisiert, wenn Du den raspberry neu aufgesetzt hast?

Viele Grüße
Jürgen

[Zeitisen]

Sorry, natürlich Bullseye, Buster fängt auch mit B an, ist aber natürlich schon älter. Korrigiere ich

[Zeitisen]

Bei der vorigen Installation hatte ich auch noch andere Tools installiert und permanent zu wenig Speicher.

Speicher scheint jetzt ok zu sein. Aber jetzt eben das Problem mit piVCCU3

[juemuc]

Dann kann ich leider nicht weiter helfen.

Viele Grüße
Jürgen

Tipp: Ich würde einmal FHEM als Grundinstallation mit piVCCU3 testen. Wenn das stabil läuft, liegt es an etwas anderem.

[Wernieman]

Schein ein Problem von eq zu sein, siehe u.a. https://github.com/jens-maus/RaspberryMatic/issues/703 oder noch mehr mit Hilfe von Google

Dort steht auch:

Restarting the HMIPServer solves the problem

[1.fhemtester]

Schau mal hier

MiB Swap:    100,0 total,      0,1 free,    99,9 used.    216,0 avail Spch

kein Swapspeicher verfügbar. Versuch den Swap größer zu machen. Manche Programme/Bibliotheken verlangen nach Swap auch wenn noch echter Speicher frei wäre.

[Wernieman]

Bei einer SD ist Swap aber gerne der "SD-Killer" ..... man sollte eher gucken, WARUM wird so viel Speicher verbraten ..

[Zeitisen]

Danke für die vielen Information.

Wie Wernieman schreibt, ist bei SD Swappen Gift und ich würde hier eher dazu tendieren, den SWAP-Speicher ganz zu entfernen. Bei PC-Distributionen wird aktuell gar kein SWAP mehr eingerichtet. Damit muss ich mich noch beschäftigen. Ich war eigentlich der Meinung, dass Swap vom Betriebsystem verwaltet wird und nicht von einer Software nach Belieben. Aber dazu weiß ich zu wenig.

Zum Fehler von eQ3: Natürlich behebt ein Neustart das Problem bis zum nächsten Auftauchen, bei mir zur Zeit circa einmal am Tag. Das hilft aber nicht weiter.

Erstaunlich ist, dass das Problem seit 2019 bekannt ist und es immer noch keine Lösung gibt. Ich hoffe, dass da @alexreinert etwas dazu sagen kann.

Wenn ein defektes Gerät so etwas bewirken kann, dann sollte die Software schon mal genauer untersucht werden. Ein defektes Gerät sollte eine Fehlermeldung zur Folge haben, am besten so, dass Rückschlüsse auf die Ursache möglich sind, und nicht einen Absturz.

Wie ich ein defektes Gerät hier identifizieren soll, ist mir ein Rätsel.

Das ganze ist sehr frustrierend.

[Wernieman]

Nur leider können wir Dir damit wenig helfen ...

Das dieses Problem schon "so alt" ist, würde (ich persönlich) die Probleme an Deiner stelle durch Hardware trennen. Also ein Pi für FHEM und einen für die piVCCU3 .... dann funzt wenigstens FHEM noch, wenn die piVCCU3 ein Problem hat ...

P.S. hast Du den Pi rebootet oder nur die piVCCU3 zur Problemlösung?

P.P.S. den Swap gaaaaaans zu entfernen hat auch so seine Nachteile. Würde ich jetzt auch nicht so grundsätzlich machen. Häufig wird bei Deskopsystemen heut anstatt eine SWAP-Partition eine SWAP-Datei verwendet ....
Eher kann man an der SWAPPINES drehen

Auch wenn für Ubuntu gielt es auch für andere Linux-Systeme, siehe unter "Swap einstellen" https://wiki.ubuntuusers.de/Swap/

Zum "schnellen Ausprobieren":

Code Auswählen Erweitern

sudo sysctl vm.swappiness=25
Standard ist übrigens 60 ..... ich (persönlich) würde für einen PI ~20 setzen (0=kein Swap, 100=sofort Swap)

[Zeitisen]

würde (ich persönlich) die Probleme an Deiner stelle durch Hardware trennen.

Das würde vielleicht die Bedienbarkeit von fhem gewährleisten, nicht aber die Funktion, wenn über die Hälfte der EAs HomematicIP sind.

hast Du den Pi rebootet oder nur die piVCCU3 zur Problemlösung

Je nach Schwere. Wenn sich alles aufhängt, kein Webaccess und kein ssh mehr geht, dann bleibt nur noch Stecker ziehen.

Das mit der Swappiness werde ich mal probieren.

[Wernieman]

dann bleibt nur noch Stecker ziehen.

^
Kann beim Pi leider dazu führen, das die SD beschädigt wird ... ich hoffe Du hast ein Backup?

Trennung von FHEM und piVCC hätte auch die Vorteile:
- komplette pi Ressoucen für die piVCC
- bessere Reaktion auf Probleme der piVCCU (z.B. getrickerter Neustart o.Ä.)

Nur wie ich schrieb" ich würde.." bedeutet impliziert, das es für andere anders aussehen kann.

Nur s.o. wird Dir hier im Thread bei diesem Problem wahrscheinlich keiner helfen können.

Und die SWAPPINES ändern wird Dir nicht Helfen, war her ein Hinweis auf den Vorherigen Beitrag bezüglich "SWAP entfernen".

[Zeitisen]

So, jetzt habe ich mal die Swap Size auf 200 gesetzt und die swapiness auf 1. Wenn es wirklich klemmt, ist noch Reserve. Bis jetzt sind davon 5,8 MB benutzt (wer macht denn sowas, wenn 150 Mbyte Cache und 90MB komplett frei sind?).

Die piVCCU habe ich jetzt aktualisiert auf 3.71.12 aus testing. Die ist noch warm.
Neue Version, neues Glück.

[deimos]

Hi,

das Problem ist, dass der HmIPServer keine Daten mehr vom Kernelmodul entgegen nimmt und irgendwann der (statisch initialisierte) Puffer voll ist und dann kommt eben diese Fehlermeldung im Kernelmodul, wenn weitere Daten vom Funkmodul kommen. Mit einem Speicherproblem hat das wenn überhaupt nur indirekt zu tun.
Ich kann mir da an sich nur drei Sachen vorstellen: Java Garbage Collector dreht hohl, ein Deadlock im HmIPServer oder eine externe Blockierung durch eine RPC Verbindung. Oder natürlich eine Kombination davon.
Aufgrund dessenund dem Problem, dass SD Karten es hassen, würde ich den Swap Speicher eher komplett deaktivieren, im Zweifel muss man eben einsehen, dass der Speicher eines Pis zu klein ist für piVCCU, FHEM und noch node.js.
Die 3.71.12 wird vermutlich nichts ändern, ich habe da keine wirklichen Änderungen an den hierfür relevanten Stellen gesehen.

Viele Grüße
Alex (alexreinert)

[Zeitisen]

Danke für die Info.
Das mit dem Speicher sehe ich auch unkritisch, zumal jetzt ja genügend Speicher vorhanden ist.
Die Sache mit dem Swap ist nur ein Geplänkel am Rande. Wenn schon Infos dazu kommen, dann probiert man halt mal etwas.

RPC: Ich habe jetzt in fhem nur noch zwei RPCs am laufen: BidCos-RF und HMIP-RF. Die Virtual Devices habe ich entfernt, weil ich sie nicht brauche. Das spart auch 200MB Speicher.

Deadlock im Speicher, Blockierung durch RPC: Wie kann man da weiterkommen? Kann ich irgendwelche Information aus Logs auslesen? Sind noch andere Informationen wichtig?