HomeMatic-Forum / FHZ-Forum

Hallo!
Sehr häufig ist die von mir als enocean-Gateway genutzte CCU2, auf der die piotek(???) cuxg-Software läuft, zu 100% ausgelastet. Ein Neustart beseitigt die Situation für eine Weile. Eigentlich sollte doch die lediglich zum Weiterrouten von commands genutzte CCU2 so gut wie nix zu tun haben, oder???? Kann leider die Fehlerursache nicht finden. Folgend der OUTPUT vom ps -ef Command:
PID USER COMMAND
1 root init
2 root [kthreadd]
3 root [ksoftirqd/0]
5 root [kworker/u:0]
6 root [rcu_kthread]
7 root [khelper]
8 root [kdevtmpfs]
9 root [netns]
10 root [sync_supers]
11 root [bdi-default]
12 root [kintegrityd]
13 root [kblockd]
14 root [rpciod]
15 root [kworker/0:1]
16 root [kswapd0]
17 root [fsnotify_mark]
18 root [nfsiod]
19 root [crypto]
24 root [mtdblock0]
25 root [mtdblock1]
26 root [mtdblock2]
27 root [mtdblock3]
28 root [mtdblock4]
29 root [mtdblock5]
30 root [mtdblock6]
31 root [mtdblock7]
32 root [ubi_bgt0d]
33 root [ubi_bgt1d]
34 root [kworker/u:1]
37 root [deferwq]
38 root [devfreq_wq]
43 root [ubifs_bgt1_0]
82 root [eq3spi.0]
89 root [file-storage]
92 root [khubd]
113 root /usr/sbin/crond
116 root /sbin/syslogd -m 0
118 root /sbin/klogd
122 root /sbin/syslogd -m 0
124 root /sbin/klogd
127 root /lib/udev/udevd -d
141 root watchdog -t 30 /dev/watchdog
156 root /lib/udev/udevd -d
157 root /lib/udev/udevd -d
158 root udhcpd -S /etc/udhcpd.usb0.conf
264 root udhcpc -x hostname homematic-ccu2 -V eQ3-CCU2 -b -s /bin/dhcp.script
270 root /usr/sbin/ifplugd -i eth0 -fI -u0 -d10
286 root [kworker/0:2]
296 root /bin/eq3configd
297 root /bin/ssdpd
308 root ntpclient -h ntp.homematic.com -l
328 root /usr/local/addons/cuxg/cuxd
347 root {tty2tcp} /bin/sh extra/tty2tcp start ttyAPP1 57600 54321
349 root {tty2tcp} /bin/sh extra/tty2tcp start ttyACM0 57600 54323
353 root /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
392 root /bin/multimacd -f /etc/config/multimacd.conf -l 5
407 root /sbin/getty -L ttyAMA0 115200 vt100
408 root /sbin/getty -L ttyGS0 115200 vt100
464 root /usr/local/addons/cuxg/extra/socat tcp-l:54321,reuseaddr file:/dev/ttyAPP1,nonblock
11737 root sleep 10
11738 root /www/addons/cuxg/index.ccc
11739 root sh -c ps -ef 2>&1
11740 root ps -ef

Kann jemand helfen??????????????

Dass muss sich der CUxD Progrsmmierer mal anschauen ....
Wird aber erst kommende Woche sein ....

toli57 hat geschrieben: ↑

28.05.2021, 08:33

Kann jemand helfen??????????????

Schau doch mal mittels top-Befehl, welcher Prozess das verursacht.

Hallo!
Danke für den Tipp! Kenne mich im unix nicht so gut aus, deshalb bin ich nicht selbst drauf gekommen! Aber wie es der Zufall so will, läuft die CCU2-cuxg seit Tagen ohne Probleme! Ich melde mich, wenn neue Erkenntnisse/ Info's vorliegen ..

toli57 hat geschrieben: ↑

31.05.2021, 13:50

Kenne mich im unix nicht so gut aus,

Der Aufruf müsste so lauten:

Spät kommt mein Dank für die Command-Spezifikation!! ... aber er kommt! Es ist unglaublich ... das "Murphy-Gesetz" scheint wieder einmal zuzuschlagen! Ich hatte definitiv im letzten Monat (05/2021) zig mal diese nervige 100%-ige CPU-Auslastung bei dem CCU2-enocean-Gateway! Seit dem ist es nie wieder aufgetreten??? Verstehe ich nicht! Naja, was soll's! Ich beobachte das - z.Zt. nicht auftretende 100%-Auslastungsproblem - definitiv weiter und melde mich bei Vorliegen neuer Erkenntnisse! Sorry!

Ob meine im Alter zu nehmenden Alzheimer-Symptome die Ursache sind?

Gruß aus dem Süden Berlin's...

Heute ... jetzt ist die Situation wieder aufgetreten: 100% CPU auf dem cuxg-Gateway auf der CCU2. Ich habe den o.g. command ausführen können. Ergebnis:
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
310 1 root R 3712 1% 81% /bin/ssdpd
19056 19055 root R 2380 1% 19% top -b -n 1
Mein Verständnis: Der top-command selbst hat 19% verbraucht??? Wäre nett, mir könnte jemand Sinn und Zweck des 81%-igen CPU-Verbrauches des anderen Prozesses /bin/ssdpd erklären? Der Dank für eine Erklärung - von uwe(???) -sei vorweg genommen ...

toli57 hat geschrieben: ↑

03.07.2021, 17:43

Der Dank für eine Erklärung - von uwe(???) -sei vorweg genommen ...

Keine Ahnung, damit kenne ich mich leider nicht aus.

Wie sieht denn die komplette Ausgabe aus?
Stehen im Kernel-Log irgendwelche Meldungen?

Ist zwar RaspberryMatic, aber mit dem "ssdpd" gab es schon mal Probleme...
viewtopic.php?f=65&t=42501

"Meine" Situation ähnelt der in dem o.g. link beschriebenen sehr! Was waren signifikante Ereignisse: Vorgestern gab es einen CCU3-Restart! Nach dem gestrigen Auftreten des 100%-CCU2-Auslastungsproblems fiel auf, dass auch die CUxd-Oberfläche der Zentrale-CCU3 nicht erreichbar war! Auffällig ist weiterhin, dass eine nicht erreichbare CUxD-Wartungs-Oberfläche relativ häufig nach CCU3-Restarts auftritt! Ein Restart CUxD löst dann i.d.R. das Problem. Bei konstant und ununterbrochen laufendem Netzwerk - alle Komponenten aktiv - tritt die Situation nicht auf! Nach einem Restart von einer der 3 Fitzboxen (Mesh-Verbund) oder der Homematic-Zentrale (CCU3) erscheint der Fehler i.d.R. innerhalb der nächsten ca. 24h! Ich warte jetzt auf das nächste Auftreten ... und werde dann das Kernel-log durchsuchen!