Sporadische Programmverzögerung unerklärbar
Moderator: Co-Administratoren
Re: Sporadische Programmverzögerung unerklärbar
Hallo,
ich hatte ein (ähnliches) Problem mit extremen Programmverzögerungen seit ich auf 3.59.6 aktualisiert habe - nur DV haben noch einwandfrei funktioniert. Alles andere +/- 1 Minute verzögert. Zuletzt ist mir ein "child process" in CuxD aufgefallen, der dem CuxD Ping (welchen ich gar nicht mehr verwendete) zuzuordnen war. Das Gerät habe ich gelöscht und seitdem funzt es wieder . Vielleicht hilft es ja...
Liebe Grüße,
Olaf
P.S.: Hatte zuvor auch CuxD-Timer in verdacht...
ich hatte ein (ähnliches) Problem mit extremen Programmverzögerungen seit ich auf 3.59.6 aktualisiert habe - nur DV haben noch einwandfrei funktioniert. Alles andere +/- 1 Minute verzögert. Zuletzt ist mir ein "child process" in CuxD aufgefallen, der dem CuxD Ping (welchen ich gar nicht mehr verwendete) zuzuordnen war. Das Gerät habe ich gelöscht und seitdem funzt es wieder . Vielleicht hilft es ja...
Liebe Grüße,
Olaf
P.S.: Hatte zuvor auch CuxD-Timer in verdacht...
Über CCU2 steuerbar: 60 Geräte, 128Kanäle, MobotixT25, M12, 14 Philips Hue, Gartenbewässerung 5-Linien.
-
- Beiträge: 52
- Registriert: 07.10.2016, 13:44
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 1 Mal
Re: Sporadische Programmverzögerung unerklärbar
Hallo Olaf, danke für deinen Tipp.
Ich habe diese Geräte: Mit diesen Details:
Was meinst Du denn mit einem Child Prozess?
Sind in meinen Geräten oben evtl. verdächtige Dinge dabei?
Danke!
Ich habe diese Geräte: Mit diesen Details:
Code: Alles auswählen
Aktuelle Geräteeinstellungen - 4 Gerät(e), 38 Channel(s):
CUX2801001:1 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT(cat /boot/VERSION)
KEY-LONG CMD_LONG()
CUX2801001:2 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT(wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js')
KEY-LONG CMD_LONG()
CUX2801001:3 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:4 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:5 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:6 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT(/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
KEY-LONG CMD_LONG()
CUX2801001:7 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:8 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:9 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT((echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status)
KEY-LONG CMD_LONG()
CUX2801001:10 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:11 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:12 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:13 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:14 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:15 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801001:16 rmax(65535) t(7200s) p(0)
KEY-SHORT CMD_SHORT(monit restart rfd)
KEY-LONG CMD_LONG()
CUX2801002:1 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801002:2 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801002:3 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX2801002:4 rmax(65535) t(3600s) p(0)
KEY-SHORT CMD_SHORT()
KEY-LONG CMD_LONG()
CUX9002001: mode(3) T h(0.40)
CUX9002001:1 SET
CUX9002001:2 SET
CUX9002002: mode(1) T h(0.40)
CUX9002002:1 SET
CUX9002002:2 SET
gefundene Adressen f(3) (aktuelle zuerst 07:48:45):
Sind in meinen Geräten oben evtl. verdächtige Dinge dabei?
Danke!
Re: Sporadische Programmverzögerung unerklärbar
Hallo,
ein Child-Prozess ist ein Prozess der von CuxD angestossen ist und läuft. Ich hatte ein virtuelles CuxD-Gerät installiert welches zyklisch (jede Minute) einen Ping gesendet hat. Offenbar hat dies in der neuen Firmware die Abarbeitung andere Befehle verzögert. Im Bild ist der Child-Prozess dargestellt der gestartet wird, wenn man in CuxD das Sys-Backup macht... Ggf. beobachten, ob da was auffällt. Da Du dieses Gerät nicht hast, würde ich mir andere zyklisch aufgerufene Prozesse, Programme anschauen (z.B. über Status wann zuletzt aufgerufen, damit man einschätzen kann, ob eines zu häufig ausgeführt wird), ggf. CuxD-Timer o.ä.. Bin da eher trial and error als systematisch... Deine Geräte kann ich nicht einschätzen, habe aber ein paar mehr laufen... Ich weiss wie nervig das ist - hat bei mir auch einen Monat gedauert, bis ich die Zeit hatte mal tiefer ins System zu schauen...
Viel Erfolg,
Olaf
ein Child-Prozess ist ein Prozess der von CuxD angestossen ist und läuft. Ich hatte ein virtuelles CuxD-Gerät installiert welches zyklisch (jede Minute) einen Ping gesendet hat. Offenbar hat dies in der neuen Firmware die Abarbeitung andere Befehle verzögert. Im Bild ist der Child-Prozess dargestellt der gestartet wird, wenn man in CuxD das Sys-Backup macht... Ggf. beobachten, ob da was auffällt. Da Du dieses Gerät nicht hast, würde ich mir andere zyklisch aufgerufene Prozesse, Programme anschauen (z.B. über Status wann zuletzt aufgerufen, damit man einschätzen kann, ob eines zu häufig ausgeführt wird), ggf. CuxD-Timer o.ä.. Bin da eher trial and error als systematisch... Deine Geräte kann ich nicht einschätzen, habe aber ein paar mehr laufen... Ich weiss wie nervig das ist - hat bei mir auch einen Monat gedauert, bis ich die Zeit hatte mal tiefer ins System zu schauen...
Viel Erfolg,
Olaf
Über CCU2 steuerbar: 60 Geräte, 128Kanäle, MobotixT25, M12, 14 Philips Hue, Gartenbewässerung 5-Linien.
-
- Beiträge: 236
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: Sporadische Programmverzögerung unerklärbar
meine 2ct dazu :schonwiederich hat geschrieben: ↑08.10.2021, 07:53Sind in meinen Geräten oben evtl. verdächtige Dinge dabei?
- "verdächtige Geräte" sehe ich zwar nicht
- jedoch bin ich bei deinen vielen cuxd-cmds etwas skeptisch, hier besteht wohl da Risiko, dass etwas hängen bleibt
- und im Log sehe ich viele Dinge, die zur vollen Minute quasi gleichzeitig getriggert werden, u.a. eine Menge einzelne cuxd-cmds für die Systeminfos MEM, TEMP, CPU, etc.
- "wget" : hier würde ich IMMER einen Timeout einbauen kleiner 2-3 sec, z.B. "-T 2" oder auch "--timeout=2". Es ist eben nicht vorhersehbar, ob nicht doch mal DNS länger braucht, sie Site mal eben offline ist oder auch nur länger braucht.
- was macht eigentlich der Befehl "(echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status" genau, bzw. wie lange dauert das, wenn du ihn mal auf einer Shell-console laufen läßt ?
- die Timersteuerungen entzerren, muss bestimmt nicht alles zur vollen Minute laufen. OK, Die CCU-Zeitsteuerung kann wohl bloß Minuten, der CUxD-Timer ist da schon eleganter . Oder einfach das Programm sich selbst retriggern lassen z.B für eine SV als Zahl wie CPU-Temperatur: wenn SV größer gleich -10, dann skript verzögert um 313 sec. Dann läuft des beim Booten und danach alle 5min13sec
- sie SystemInfos kann man auch in EINEM cmd zusammenfassen, hab ich bei mir auch so gemacht.
- CuxD-CMDS : bei kritischen Aufrufen, die länger dauern können, ist ein CallBack sinnvoll. das hatte @Black HIER mal schön beschrieben und ist auch im CUXD-Handbuch 2.6, Seite 108 drin. Kurz : nehme CMD_RUNS bzw. CMD_RUNL und werte das Ergebnis asynchron in einem extra Programm aus.
- ich würde auch empfehlen, systematisch die CUxD-Aufrufe einen nach dem anderen mal deaktivieren, um hier den ggf. "Schuldigen" zu finden
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Sporadische Programmverzögerung unerklärbar
Schickt via telnet einen Ausgabe und einen Wartebefehl von 50.000 Mikrosekunden an einen externes Gerät (in einem anderen Adressbereich). Und wenn dann auf die Antwort (eines ggf. nicht erreichbaren Gerätes) gewartet wird, ist eine Verzögerung bis zum Timeout nicht verwunderlich. Und das passiert natürlich nur, wenn der Kanal CUX2801001:9 angesprochen wird.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 9679
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: Sporadische Programmverzögerung unerklärbar
Womit wir wieder beim Beitrag 2 wären.
Aber das wurde ja verneint...
Aber das wurde ja verneint...
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Sporadische Programmverzögerung unerklärbar
Oder mit explizitem Hinweis auf die (immer wieder gleiche) Ursache in meinem Post vom 15.09.2021 22:28 Uhr in diesem Thread. Nicht umsonst bin ich der (immer wieder kommunizierten) Meinung, dass die CCU-Firmware nicht für derartige externe Kommunikation geeignet ist, die nicht dem eigenen Einfluss unterliegt. Und trotzdem werden die Scriptingjünger nicht müde, immer wieder irgendwelche Scripte aus dem Hut zu zaubern, die externe Server abfragen. Aus einer Wetterabfrage lässt sich ja wenigstens noch teilweise ein Sinn für die Hausautomation ableiten, aber was eine CCU beispielsweise mit Spritpreisen soll, konnte mir noch keiner schlüssig erklären.
Gruß Xel66
Zuletzt geändert von Xel66 am 09.10.2021, 12:08, insgesamt 1-mal geändert.
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 9679
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: Sporadische Programmverzögerung unerklärbar
Man muss nur vernünftig mit timeout arbeiten.Aber bei den Sprit Preisen muss ich dir zustimmen.
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Sporadische Programmverzögerung unerklärbar
Den musst Du dann aber auch ausreichend klein halten, damit es nicht zu Verzögerungen kommt. Viele von den dann ggf. auftretenden Verzögerungen, werden bei automatischen Steuerungen nicht vom Anwender bemerkt. Er stößt nur dann drauf, wenn auf eine Tastenbetätigung ein Programm nur mit Verzögerung läuft.
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 236
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: Sporadische Programmverzögerung unerklärbar
apropos "Timeouts" : bei wget reicht es nicht, nur den Timeout (default read timout = 900s !!) zu setzen ... wget versucht es auch bei Timeouts immer wieder ... und hängt dadurch ggf.
Wichtig scheint mir bei wget die Kombination von Timeout und Anzahl der Versuche = tries, z.B.
"--timeout=2 --tries=1" oder "-T 2 -t 1" bedeutet eben nur einen Versuch und dabei eben nur 2sec warten.
Ansonsten wiederholt wget zig mal (default=20) den Versuch die URL zu erreichen macht also hier im Beispiel 2*20sec = 40sec PAUSE !!
Das gilt wohl auch für Versionsabfrage im RM per : wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/Raspb ... VERSION.js'. bei irgendwelchen DNS/Server-Problemchen, dauert dieser Befehl wohl etwas länger als üblich Wozu soll dieses wget im RM eigentlich gut sein ? alle 5 min auf die Versionsnummer zuzugreifen ? is mir grad etwas unverständlich ...
Ich vermute wie andere hier auch, dass die recht häufigen CUxD-CMDs doch mal zufällig etwas verzögern können. Man sollte mMn. solche Befehle vorher in der Shell mal manuell testen mit ein paar Fehlerszenarien wie falcher URL, Port etc und die Laufzeit dabei im Auge behalten. Für mich sind cmds, die unter irgendwelchen Umständen länger als 2 sec brauchen, eben in einem Skript nicht mehr brauchbar.
Lassen wir den TE das alles mal "sacken" lassen und warten auf eine Rückmeldung
Wichtig scheint mir bei wget die Kombination von Timeout und Anzahl der Versuche = tries, z.B.
"--timeout=2 --tries=1" oder "-T 2 -t 1" bedeutet eben nur einen Versuch und dabei eben nur 2sec warten.
Ansonsten wiederholt wget zig mal (default=20) den Versuch die URL zu erreichen macht also hier im Beispiel 2*20sec = 40sec PAUSE !!
Das gilt wohl auch für Versionsabfrage im RM per : wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/Raspb ... VERSION.js'. bei irgendwelchen DNS/Server-Problemchen, dauert dieser Befehl wohl etwas länger als üblich Wozu soll dieses wget im RM eigentlich gut sein ? alle 5 min auf die Versionsnummer zuzugreifen ? is mir grad etwas unverständlich ...
Ich vermute wie andere hier auch, dass die recht häufigen CUxD-CMDs doch mal zufällig etwas verzögern können. Man sollte mMn. solche Befehle vorher in der Shell mal manuell testen mit ein paar Fehlerszenarien wie falcher URL, Port etc und die Laufzeit dabei im Auge behalten. Für mich sind cmds, die unter irgendwelchen Umständen länger als 2 sec brauchen, eben in einem Skript nicht mehr brauchbar.
Lassen wir den TE das alles mal "sacken" lassen und warten auf eine Rückmeldung
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1