Remote-Support-Client nimmt zunehmend mehr Speicher in Anspruch

[ChristophR]

Wenn er nicht ins Internet kommt, könnte er sich ja auch für ein paar Minuten schlafen legen und es dann nochmal probieren. Der sollte doch eh immer schlafen und darauf warten, von draußen angestupat zu werden, oder? Gut, er muss auch noch regelmäßig nachkucken, ob seine nach draussen kommunizierte Adresse immer noch gültig ist.

Das ist im Grunde ja die selbe Logik wie bei DynDNS, hier verwendet für Support und Cloud.

Es ist ja eine ausgehende Verbindung, er kann nur angestupst werden, wenn er die Verbindung hergestellt hat.

[zut]

Der Client wird erst mit dem ersten Einloggen in der Cloud gestartet, das startende Script ist remoteSupport.py unter runs/remoteSupport/. Ich kann mir vorstellen, das das Script nach einer Inaktivität den Client auch wieder herunterfahren könnte.

Vermutlich muss dafür nur die Botschaft "stop" vom richtigen User an openwb-remote/cloud gesendet werden. Wenn ich das mit mqtt Explorer versuche, bleibt es leider wirkungslos.

[ChristophR]

Vermutlich hat der OOM-Killer des Kernels den Remote Client als Speicherschwein identifiziert und beendet.

War zu erwwarten.

Code: Alles auswählen

[119601.755900] Out of memory: Killed process 14979 (lt-armv7l_ELF) total-vm:809772kB, anon-rss:535280kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:600kB oom_score_adj:0

Nachdem jetzt klar ist, dass der Client frei dreht, wenn er kein Internet findet, kann er sich (als Workaround) nicht selbst neu starten, wenn er keine Verbindung hinkriegt?
Ohne Internetverbindung ist er ja vermutlich gar nicht so wichtig...

Hilft wahrscheinlich gar nicht.
Ich habe gerade eine Unterbrechung der Internetleitung manuell ausgelöst, Verbindung steht seit 16:17 Uhr wieder.
Das hochlaufen vom RAM erfolgt aber erst danach:

Screenshot_20250910-162219.png

(240.27 KiB) Noch nie heruntergeladen

Screenshot_20250910-162918.png

(581.35 KiB) Noch nie heruntergeladen

Heute Vormittag hatte ich es schonmal versucht, da ist aber nix passiert.

P.S: Ich habe die Box dadurch abgeschossen, jetzt geht nix mehr...

[Gero]

Bei mir ist es mal wieder soweit. Gestern abend hatte ich paar-und achtzig Prozent Speicherauslastung und heute früh hängt's. Pingen tut die Box, aber die Webseiten werden nicht ausgeliefert - auch die von der Ramdisk nicht, die ja eigentlich nichts mit dem mosquitto zu tun haben sollte. Das Main-UI bleibt hier hängen:

main.jpg

(264.23 KiB) Noch nie heruntergeladen

Auf der maintenance-Seite steht schon seit zig-Minuten "Lade Daten..." und der MQTT-Explorer hat sich irgendwann mit "Disconnected from server" abgemeldet. Erstaunlicherweisehat er es beim ersten connect geschafft, sich am mosquitto anzumelden und zeigt die Hierarchie aber nur alte Werte. Irgendwann hat er sich dann aber abgemeldet. Auf dem Display steht dass der Starvorgang noch nicht abeschlossen wäre und dass das Display-Theme gestartet werden würde.

Oha - ich komme gerade von der Sicherung aussstellen wieder und muss feststellen, dass sich die leere Main-UI-Seite wieder zeigt und die maintenance-Seite ist mittlerweile gekommen. Richtige Daten sind ja nicht drauf, Box ist ja stromlos. Aber das ist ein deutliches Zeichen dafür, dass sich die Box "erholt". Nun gehe ich mal und mache die Sicherung wieder rein.

meme.jpg

(958.23 KiB) Noch nie heruntergeladen

[ChristophR]

Ich habe gestern auf das letzte Beta.2 Release aktualisiert, da ich gesehen habe, dass ein Fix für das Display (Restart) eingebaut wurde.
Seitdem ist das Verhalten des Remote-Clients so, dass er zwar nach einer Trennung der Internetleitung im RAM hochläuft, aber nach 2-3 Minuten dann beendet wird.
Zu diesem Zeitpunkt war die RAM-Auslastung global bis ca. 80%, daher sollte er ja noch nicht als Speicherschwein abgeschossen worden sein.
Aktuell läuft bei mir also nur noch der RAM eines python3 Prozesses hoch, er beginnt nach dem Neustart mit knapp unter 10%, aktuell, nach 1 Tag, liegt er bei 25%. Mal sehen, wie sich das weiter entwickelt.