Remote-Support-Client nimmt zunehmend mehr Speicher in Anspruch

[LutzB]

Der Fix wurde am 29.07. gemerged.

[zut]

Der Fix wurde am 29.07. gemerged.

Wenn ich github richtig lese, ist das am 1.8. auch in die 2.1.7-patch5 reingekommen. Diese hatte ich in diesem Beitrag schon am laufen (Update am 2.8.): viewtopic.php?p=131544#p131544 - der Fehler trat weiterhin auf.

Momentan habe ich 2025-08-22 14:47:32 +0200 [20d3363ec] und der Speicherlog sieht so aus:

Bildschirmfoto_20250828_132143.png (37.85 KiB) 505 mal betrachtet

Ich werde also dieses Wochenende einmal mit der App per Cloud zugreifen und schauen, was passiert. Ich melde mich ein paar Tage nach Cloud-Zugriff wieder.

[zut]

Ich habe jetzt heute mittag einen Cloud-Zugriff gestartet. In der Folge ist lt-armv7l_ELF gestartet und nimmt sich stetig langsam mehr Speicher.
Wann soll das Programm eigentlich terminieren? Kommt irgendwann eine payload "stop"?

remote_support.log:

Code: Alles auswählen

2025-08-22 15:05:24,647 - {RemoteSupport:219} - {INFO:MainThread}: Starting remote support client
2025-08-22 15:05:24,647 - {RemoteSupport:220} - {DEBUG:MainThread}: openWB remote support client v1.0.0 (API v1)
2025-08-22 15:05:24,648 - {RemoteSupport:221} - {DEBUG:MainThread}: registering signal handlers
2025-08-22 15:05:24,810 - {RemoteSupport:68} - {DEBUG:MainThread}: System Info:
2025-08-22 15:05:24,811 - {RemoteSupport:69} - {DEBUG:MainThread}: Architecture: (('32bit', 'ELF'))
2025-08-22 15:05:24,811 - {RemoteSupport:70} - {DEBUG:MainThread}: Machine: armv7l
2025-08-22 15:05:24,811 - {RemoteSupport:71} - {DEBUG:MainThread}: Node: openwb-2
2025-08-22 15:05:24,819 - {RemoteSupport:72} - {DEBUG:MainThread}: Platform: Linux-6.1.21-v7+-armv7l-with-glibc2.31
2025-08-22 15:05:24,819 - {RemoteSupport:73} - {DEBUG:MainThread}: System: Linux
2025-08-22 15:05:24,819 - {RemoteSupport:74} - {DEBUG:MainThread}: Release: 6.1.21-v7+
2025-08-22 15:05:24,820 - {RemoteSupport:75} - {DEBUG:MainThread}: using binary: 'lt-armv7l_ELF'
2025-08-22 15:05:24,821 - {RemoteSupport:230} - {DEBUG:MainThread}: connecting to broker
2025-08-22 15:05:24,824 - {RemoteSupport:232} - {DEBUG:MainThread}: starting loop
2025-08-22 15:05:24,826 - {RemoteSupport:106} - {INFO:Thread-1}: Connected
2025-08-22 15:05:24,829 - {RemoteSupport:126} - {DEBUG:Thread-1}: Topic: openWB-remote/valid_partner_ids, Message: []
2025-08-22 15:06:41,531 - {RemoteSupport:126} - {DEBUG:Thread-1}: Topic: openWB-remote/valid_partner_ids, Message: []
2025-08-29 12:10:41,920 - {RemoteSupport:126} - {DEBUG:Thread-1}: Topic: openWB-remote/cloud, Message: ---;cnode11;---
2025-08-29 12:10:42,026 - {RemoteSupport:85} - {DEBUG:Thread-1}: Stopping tunnel: cloud_tunnel
2025-08-29 12:10:42,030 - {RemoteSupport:101} - {ERROR:Thread-1}: tunnel cloud_tunnel is not running.
2025-08-29 12:10:42,031 - {RemoteSupport:207} - {INFO:Thread-1}: start cloud tunnel '6f23...e660' on 'cnode11'
2025-08-29 12:10:42,098 - {RemoteSupport:210} - {INFO:Thread-1}: cloud tunnel running with pid 20632

Code: Alles auswählen

20632 openwb    20   0  771856  16232   5380 S   0,0   1,7   0:19.04 lt-armv7l_ELF  

Ich sehe außerdem das remoteSupport.py-Skript laufen, was vermutlich normal ist.

Habt ihr Interesse an einem strace des lt-armv7l_ELF?

Gegen Sonntag abend plane ich, mal nach der Speicherbelegung zu schauen.

[zut]

Es ist schon jetzt offensichtlich: Seit dem ersten Zugriff auf die cloud über die OpenWB-App läuft der remote-client. Dieser nimmt kontinuierlich mehr Speicher in Beschlag und scheint nicht zu terminieren:

Bildschirmfoto_20250831_092812.png (36.05 KiB) 392 mal betrachtet

Code: Alles auswählen

top - 09:13:22 up 8 days, 18:08,  2 users,  load average: 0,51, 0,76, 0,94
Tasks: 177 total,   4 running, 171 sleeping,   0 stopped,   2 zombie
%CPU(s): 20,2 us,  4,3 sy,  0,0 ni, 74,6 id,  0,0 wa,  0,0 hi,  1,0 si,  0,0 st
MiB Spch:    922,3 total,     42,8 free,    386,9 used,    492,6 buff/cache
MiB Swap:    100,0 total,      0,0 free,    100,0 used.    446,0 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                                                                                  
20632 openwb    20   0  780564  95592   2616 S   0,0  10,1   7:44.39 lt-armv7l_ELF                                                                                                           
 1367 openwb    20   0  430224  90948  31704 S  17,6   9,6   1405:00 chromium                                                                                                                
 1694 openwb    20   0  340520  86396   9100 S  36,5   9,1   2769:44 python3                                                                                                                 
 1069 openwb    20   0  695168  76820  29508 S   0,7   8,1  42:18.06 chromium                                                                                                                
 1307 openwb    20   0  307772  25708  22640 S   0,7   2,7  50:56.27 chromium                                                                                                                
 1302 openwb    20   0  524020  21564  18552 S   0,3   2,3 214:36.70 chromium                                                                                                                
  610 root      20   0  211588  20176  15844 S   0,0   2,1   2:50.43 apache2                                                                                                                 
 1267 openwb    20   0  224384  18196  16124 S   0,0   1,9   0:00.19 chromium               

Aus meiner Sicht hat lt-armv7l_ELF also ein Speicherleck, was nicht so schlimm wäre, wenn der Client nach einiger Zeit geschlossen würde.
Eine Anmeldung an der Cloud von meinem Desktop-Rechner aus erzeugt keine neuen Einträge in remote_support.log

Was mir gerade auffällt: Normalerweise zeigt strace alle paar Sekunden Aktivitäten des clients. Nachdem ich mich gerade vom Desktop angemeldet habe, bleibt strace zumindest minutenlang still - auch eine Anmeldung aus der App ändert daran nichts:

Code: Alles auswählen

pi@openwb-2:~$ sudo strace -p 20632
strace: Process 20632 attached
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL

Dafür erzeugt der Prozess jetzt eine nennenswerte Systemlast. Vermutlich ist er mit sich selbst beschäftigt und erzeugt keine Systemaufrufe mehr:

Code: Alles auswählen

Tasks: 176 total,   2 running, 173 sleeping,   0 stopped,   1 zombie
%CPU(s): 10,8 us,  3,5 sy,  0,0 ni, 84,8 id,  0,1 wa,  0,0 hi,  0,8 si,  0,0 st
MiB Spch:    922,3 total,     34,5 free,    440,3 used,    447,6 buff/cache
MiB Swap:    100,0 total,      0,0 free,    100,0 used.    393,3 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                                                                                  
 1694 openwb    20   0  340520  86492   9092 S  17,8   9,2   2775:57 python3                                                                                                                 
20632 openwb    20   0  781652 154548   2748 S  14,8  16,4   8:46.35 lt-armv7l_ELF                                                                                                           
 1367 openwb    20   0  432072  92152  31344 S   5,6   9,8   1407:05 chromium                                                                                                                
  499 mosquit+  20   0   13528   6096   4564 S   2,3   0,6 301:55.12 mosquitto                                                                                                               
  535 mosquit+  20   0   24324   6512   4680 S   2,3   0,7 265:16.23 mosquitto     

Ich lasse das mal so laufen und schaue, ob der Speicherverbrauch weiter steigt.
Software der Wallbox ist 2025-08-22 14:47:32 +0200 [20d3363ec]

[openWB]

@zut
Hardware?
Selbst installiert?

[zut]

Nein, ist eine Standard+ von euch. Ich habe mir nur einen ssh-Zugang eingebaut, weil ich für meinen Kostal einen Bug behoben habe (wurde von euch übernommen)

[zut]

Sonntag abend: Der Speicherverbrauch steigt nach meinen Experimenten weiter, auch ohne APP-Zugriff. Die CPU-Last ist wieder nahe 0%.

Bildschirmfoto_20250831_213336.png (9.99 KiB) 340 mal betrachtet

strace zeigt wieder alle paar Sekunden systemcalls:

Code: Alles auswählen

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 16
setsockopt(16, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(16, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 16, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=19067, u64=7922351985343351419}}) = 0
getsockname(16, {sa_family=AF_INET, sin_port=htons(55373), sin_addr=inet_addr("192.168.1.102")}, [112->16]) = 0
getpeername(16, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, [112->16]) = 0
write(16, "\17\361\1\0\0\1\0\0\0\0\0\1\7cnode11\6openwb\2de\0\0"..., 46) = 46
read(16, 0x82dea00, 1232)               = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
epoll_pwait(3, [{EPOLLOUT, {u32=19068, u64=7922351985343351420}}], 128, 0, NULL, 0) = 1
epoll_pwait(3, [{EPOLLOUT, {u32=21189, u64=7922349923759051461}}], 128, 284, NULL, 0) = 1
futex(0x4bd0fc, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x4bd070, FUTEX_WAKE_PRIVATE, 1)  = 1
getsockopt(13, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getpeername(13, {sa_family=AF_INET6, sin6_port=htons(38119), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2a01:4f8:c013:aed1::1", &sin6_addr), sin6_scope_id=0}, [112->28]) = 0
futex(0x26200d0, FUTEX_WAKE_PRIVATE, 1) = 1
getsockname(13, {sa_family=AF_INET6, sin6_port=htons(32952), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2003:e0:1716:6c00:1ca9:606e:a03d:c0da", &sin6_addr), sin6_scope_id=0}, [112->28]) = 0
setsockopt(13, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(13, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(13, SOL_TCP, TCP_KEEPINTVL, [15], 4) = 0
setsockopt(13, SOL_TCP, TCP_KEEPIDLE, [15], 4) = 0
futex(0x242a790, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x242a550, FUTEX_WAKE_PRIVATE, 1) = 1
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20632, si_uid=1000} ---
rt_sigreturn({mask=[]})                 = 1
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20632, si_uid=1000} ---
rt_sigreturn({mask=[]})                 = 1
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20632, si_uid=1000} ---
rt_sigreturn({mask=[]})                 = 1
read(13, 0x830ec00, 1024)               = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
nanosleep({tv_sec=0, tv_nsec=3000}, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x242ac10, FUTEX_WAKE_PRIVATE, 1) = 1
read(10, 0x830f000, 1024)               = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
epoll_pwait(3, [{EPOLLIN, {u32=5035340, u64=5035340}}], 128, -1, NULL, 0) = 1
read(4, "\0", 16)                       = 1
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
epoll_pwait(3, [{EPOLLOUT, {u32=14856, u64=7922346487785208328}}], 128, -1, NULL, 0) = 1
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
epoll_pwait(3, [{EPOLLOUT, {u32=14857, u64=7922346487785208329}}], 128, -1, NULL, 0) = 1
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
epoll_pwait(3, [{EPOLLIN, {u32=5035340, u64=5035340}}], 128, -1, NULL, 0) = 1
read(4, "\0", 16)                       = 1
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
epoll_pwait(3, [], 128, 0, NULL, 0)     = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL^Cstrace: Process 20632 detached
 <detached ...>

(SIGURG kannte ich noch gar nicht)

Ich werde jetzt auf die Beta2 hochgehen - wenn ich noch etwas beitragen kann, bitte melden. Das Verhalten scheint mir reproduzierbar.

[LutzB]

Ich werde jetzt auf die Beta2 hochgehen - wenn ich noch etwas beitragen kann, bitte melden. Das Verhalten scheint mir reproduzierbar.

Das Verhalten ist hier leider gar nicht reproduzierbar. strace gibt keine Aktivität aus.

Code: Alles auswählen

strace: Process 2681 attached
futex(0x4bc9f0, FUTEX_WAIT_PRIVATE, 0, NULL

Auch der Speicherbedarf liegt hier relativ konstant bei 1%. Bei Deinem Post vom 31.08. ist sowohl Hauptspeicher als auch Swap vollgelaufen. Dass es dann zu Instabilitäten und sehr zähem Verhalten kommt, ist normal.

Aktuell haben wir keinen Ansatzpunkt für Dein Problem.

[zut]

Könnte eine Ursache sein, dass ich die ssh-Anmeldung (auch) per Passwort erlaubt habe?

In meiner Fritzbox habe ich Quad 9 als DNS Resolver eingetragen, das könnte eventuell auch relevant sein.

Ich kann mit beiden Einstellungen mal experimentieren, sobald ich die Zeit finde.

[LutzB]

SSH dürfte unkritisch sein. Den Rest kann ich nicht beurteilen.

Inzwischen ist bei mir zumindest der Speicherbedarf ebenfalls auf 1,4% angestiegen ohne weitere Interaktivität mit der Cloud. strace hingegen ist weiter unauffällig und schweigt.