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:
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:
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?
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
Sorry, natürlich Bullseye, Buster fängt auch mit B an, ist aber natürlich schon älter. Korrigiere ich
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
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.
Schein ein Problem von eq zu sein, siehe u.a. https://github.com/jens-maus/RaspberryMatic/issues/703 (https://github.com/jens-maus/RaspberryMatic/issues/703) oder noch mehr mit Hilfe von Google
Dort steht auch:
ZitatRestarting the HMIPServer solves the problem
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.
Bei einer SD ist Swap aber gerne der "SD-Killer" ..... man sollte eher gucken, WARUM wird so viel Speicher verbraten ..
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.
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/ (https://wiki.ubuntuusers.de/Swap/)
Zum "schnellen Ausprobieren":
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)
Zitatwü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.
Zitathast 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.
Zitatdann 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".
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.
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)
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?
Gibt es Wechselwirkungen, wenn ich zuvor debmatic installiert habe, und dann auf piVCCU gewechselt bin?
Ich habe die debmatic Archive entfernt. wenn ich jetzt aber
sudo dpkg-reconfigure pivccu3
Stop piVCCU ... Done
Disable services ... Done
Remove symlinks ... Done
Reload udev rules ... Done
Create symlinks ... Done
Enable services ... Done
Update APT repository config ... FAILED
sed: /etc/apt/sources.list.d/pivccu.list
/etc/apt/sources.list.d/raspi.list kann nicht gelesen werden: Datei oder Verzeichnis nicht gefunden
Error updating repo https://www.debmatic.de/debmatic in /etc/apt/sources.list.d/pivccu.list
/etc/apt/sources.list.d/raspi.list
mache, kommt eine Fehlermeldung, die für mich aber nicht nachvollziehbar ist. Die Datei /etc/apt/sources.list.d/raspi.list ist sehr wohl vorhanden und kann auch gelesen werden. updating repo https://www.debmatic.de/debmatic ist Käse. Das sollte gar nicht mehr existent sein. Wo sind diese Leichen versteckt?
Hi,
Zitat von: Zeitisen am 09 August 2023, 09:55:35Deadlock im Speicher, Blockierung durch RPC: Wie kann man da weiterkommen? Kann ich irgendwelche Information aus Logs auslesen? Sind noch andere Informationen wichtig?
Das ist leider alles im Closed Source von eQ-3, das wird also leider nur eQ-3 fixen können. Ich könnte nur im Kernel Modul die Nachrichten kommentarlos verwerfen, aber das löst halt nicht das Problem, dass dann keine HmIP Funktelegramme mehr verarbeitet werden.
Viele Grüße
Alex
Hi,
Zitat von: Zeitisen am 09 August 2023, 11:30:45Gibt es Wechselwirkungen, wenn ich zuvor debmatic installiert habe, und dann auf piVCCU gewechselt bin?
Sollte es keine geben. Den Fehler kannst du ignorieren, das ist ein Bug im Postinst Script, der in der nächste Version gefixt sein wird. Das da debmatic steht ist Absicht, ich aktualisiere beibe Repositories sowohl in debmatic, als auch in piVCCU für den Fall, dass jemand vom einem zum anderen gewechselt ist ohne die Repositories anzupassen. Rein technisch ist es nur ein Repository, welches unter zwei Domains verfügbar ist.
Viele Grüße
Alex
Danke für die Bemühungen.
Ich nehme an, dass eQ3 den Bug kennt. Vielleicht mache ich mir noch die Mühe, den eQ3 Support zu kontaktieren.