TabletUI v2 + Fully Kiosk erzeugt Server-Freezes

[stefanfo84]

Hi,

ich kämpfe jetzt seit einigen Wochen immer mal wieder (zwischendrin habe ich immer wieder frustriert aufgegeben) an folgendem Problem.

Mein Tablet UI v2 läuft in einem Fully Kiosk Browser auf einem Lenovo Tab P12 Tablet. Per Motion Detection wird der Bildschirm angeschaltet. Lief seit ca. 9 Jahren problemlos. Mein Projekt ist würde ich sagen recht umfangreich

Vor 2-3 Monaten fing es plötzlich an, dass immer wieder mein ganzer FHEM-Server hing. Der läuft in einem Docker-Container und anscheinend hängt einfach der Perl-Prozess für einige Minuten komplett, mal kürzer mal länger. Last hat das System so gut wie keine. Der Docker-Container braucht meist nur ca. 120 MB RAM, springt aber auch mal auf bis zu 450 MB. Das ist aber weit weg von meinen Limits. Das Problem äußert sich so, dass ich nicht mehr drauf komme, keine Aktionen mehr ausgeführt werden, keine Logs mehr geschrieben werden. Nach einer gewissen Zeit läuft dann alles normal weiter - Wecker "klingelt" dann nur evtl. 20 Minuten zu spät

Meine 1. Maßnahme war ein Umzug auf einen neuen Raspberry Pi 5 - der sich komplett langweilt und das Problem aber nicht gelöst hat.
Dann habe ich irgendwann festgestellt, dass das Problem mit dem Tablet zusammen hängt. Nach paar Mal aufwachen des Tablets über Fully hängt FHEM komplett. Schalte ich Fully Kiosk aus, keinerlei Hänger mehr. Auch "freezemon" hat mich auf Web-Requests hingewiesen - aber auch einige andere Hänger gemeldet, die ich eher als Fehlalarm sehen würde.
Mein Verdacht fiel dann auf longpoll, auch wenn FHEM ja eigentlich nicht komplett einfrieren sollte, wenn ein Web-Request hängt. Also habe ich auf shortpoll umgestellt. Nun hängt zumindest der Server nicht mehr, aber das TabletUI lädt ab ein paar Mal aufwecken per Motion Detection nicht mehr. Könnte gefühlt das gleiche Problem mit leicht anderer Wirkung sein.

So wirklich erklären kann ich es mir nicht. Bin zwar kein Laie, aber auch kein Experte in dieser Sache. ChatGPT hat mir auch schon ca. 1 Million Tipps gegeben, aber keiner hat geholfen.
Mein nächster Schritt wäre nun auf Fully zu verzichten und das Ganze irgendwie per Chrome und Tasker nachzubauen.
Übernächster Schritt wäre ein Versuch mit TabletUI v3.
Überübernächster Schritt wäre, was ich eigentlich nicht wollte, Umzug auf HA. Weil ich echt langsam verzweifelt bin.

Der Auslöser war möglicherweise entweder ein Update des Tablets auf Android 15 oder ein Update von FHEM auf bookworm-basiertes Image.

Hat(te) jemand ähnliche Probleme oder ist mein Setup zu einzigartig?
Irgendeine Idee, weshalb mein Server für einige Minuten einfriert, obwohl FHEM ja eigentlich Mechanismen dagegen implementiert hat?

Bin für jeden Hinweis dankbar! Gerne kann mein Beitrag auch in ein anderes Unterforum, wenn mein Problem eher zum FHEM-Core passt.

[stefanfo84]

Wie so oft, hat es mich etwas weiter gebracht, das Problem mal aufzuschreiben und zu erklären.
Zumindest eine Wurzel des Übels ist wohl Fully Kiosk mit Auto-Reload.

Beim Starten von Fully und Laden meines TabletUI werden ganze 8 Sockets aufgemacht - könnte ok sein, das habe ich noch nicht im Detail betrachtet. Bei jedem Auto-Reload kommen weitere Sockets dazu. Geschlossen werden nur sehr wenige bis gar keine.
Schon nach 5 Minuten zeigt mir dann sudo ss -tanp ein CLOSE-WAIT und der Server hängt wieder kurz.

Ob der Fehler nun hauptsächlich clientseitig bei Fully liegt (weil der seine Connections nicht ordentlich schließt oder reused) oder hauptsächlich serverseitig bei FHEM (weil dort die Connections nicht terminiert werden) oder bei Android (Energiesparptimierung ist natürlich aus) oder vor dem Bildschirm sitzt - keine  Ahnung.

Trotz deaktiviertem Auto-Reload sieht es dann nach einer Stunde wieder so aus und mein Server hängt:
sudo ss -tanp | grep 11.161
State      Recv-Q Send-Q Local Address:Port     Peer Address:Port Process
CLOSE-WAIT 584    0      192.168.11.55:8088  192.168.11.161:53240
CLOSE-WAIT 543    0      192.168.11.55:8088  192.168.11.161:53226
CLOSE-WAIT 1      0      192.168.11.55:8088  192.168.11.161:58250
CLOSE-WAIT 4880  0      192.168.11.55:8088  192.168.11.161:35650
CLOSE-WAIT 540    0      192.168.11.55:8088  192.168.11.161:53246
CLOSE-WAIT 1      60431  192.168.11.55:8088  192.168.11.161:51062 users:(("perl",pid=10875,fd=25))
CLOSE-WAIT 4906  0      192.168.11.55:8088  192.168.11.161:35638


So, nun ist weiterhin die Frage wo die vielen an Sockets herkommen und warum mein Server hängt. 6 der 7 Sockets haben anscheinend noch Daten in der Queue die noch nicht von FHEM verarbeitet wurden? Ist das aber nicht eigentlich auch egal, weil die schon auf CLOSE-WAIT rumhängen? Oder ist das was ich hier sehe nur die Folge davon, dass FHEM an was anderem hängt?

Mein nächster Versuch ist nochmal mit
attr WEBtablet longpoll websocket
Eigentlich hatte ich das auch schon ausprobiert und ich meine, dass es meine Ursprungs-Config war... aber gerade gefällt mir die Anzahl an Ports und Sockets schon mal viel besser, nämlich nur noch je 1...
ESTAB    0      65409  192.168.11.55:8088  192.168.11.161:51636 users:(("perl",pid=72741,fd=32))