Analyse Probleme mit system.Exec()

[jmaus]

Hallo Zusammen,

wie schon viele Jahre bekannt gibt es ja mit der Nutzung der system.Exec() Funktion innerhalb eines HomeMatic Skriptes gewisse Probleme die dazu geführt haben das weitläufig bekannt ist das man lieber CUxD EXEC Aufrufe verwenden sollte um Unix Programme auf der CCU auszuführen. Nun habe ich selber schon immer von Anfang an daher auf CUxD gesetzt, würde nun jedoch gerne dem Problem mal ein wenig auf den Grund gehen wollen um zu verstehen wo genau das Problem liegt bzw. welche Symptome es bzgl. system.Exec() Aufrufe gibt.

Ich würde daher gerne einmal gerade von den weitaus erfahreneren Nutzern wissen wollen welche Probleme es denn definitiv mit der system.Exec() Funktion gibt, wie die sich äußern und wie ich das hier auf einem jungfräulichen CCU2 system reproduzieren kann.

Es wäre daher schön wenn wir hier eine Aufstellung der bekannten Probleme rund um system.Exec() erstellen könnten. Wichtig wäre mir hierbei in der Tat nur Probleme zu listen/melden die sich definitiv mittels Beispielskripten auf einer jungfräulichen CCU2 reproduzieren lassen. Bitte also nur die Probleme melden für die ihr auch Beispielskripts und Beispielausgaben der Probleme parat habt oder die definitiv von mehreren Nutzern bereits verifiziert wurden.

Sinn des Ganzen soll es sein die Probleme rund um system.Exec() besser verstehen zu können und ggf. sogar Workarounds dafür so zu erarbeiten das man in Zukunft ggf. wieder problemlos auf system.Exec() (zumindest mit RaspberryMatic) setzen kann.

[BadenPower]

Ich würde daher gerne einmal gerade von den weitaus erfahreneren Nutzern wissen wollen welche Probleme es denn definitiv mit der system.Exec() Funktion gibt, wie die sich äußern und wie ich das hier auf einem jungfräulichen CCU2 system reproduzieren kann.

Als exzessiver system.Exec-User sind mir keine Probleme bekannt.

Auch ein Stresstest konnte meine Produktiv-CCU nicht beeindrucken.

Stresstest:
viewtopic.php?f=37&t=30073
.

[blackhole]

Anfang 2015 hatte ich mich von den wirklich vielen, meines Erachtens aber nicht mehr haltbaren Aussagen in Sachen system.Exec irritieren lassen und alles auf CUxD-Exec umgestellt. Heute kann ich sagen, dass system.Exec -trotz intensiver Nutzung- problemlos funktioniert.

Die Rückumstellung auf das CCU-eigene system.Exec erfolgte bei mir Mitte 2016.

[jmaus]

Anfang 2015 hatte ich mich von den wirklich vielen, meines Erachtens aber nicht mehr haltbaren Aussagen in Sachen system.Exec irritieren lassen und alles auf CUxD-Exec umgestellt. Heute kann ich sagen, dass system.Exec -trotz intensiver Nutzung- problemlos funktioniert.

Die Rückumstellung auf das CCU-eigene system.Exec erfolgte bei mir Mitte 2016.

Ok, danke für die ersten Rückmeldungen. Ich bin gespannt ob noch andere etwas diesbzgl. berichten können und ggf. sich sogar jemand findet der aktuell noch Probleme hat bzw. ein konkretes Beispiel benennen kann bei dem system.Exec() ein Problem ist (parallele Ausführung oder ähnliches).

Auch würde mich interessieren ob es irgendwelche nennenswerten Limitationen von system.Exec() gegenüber den CUxD-Exec Aufrufen gibt die eventl. beachtenswert wären. Ich möchte hier einfach mal einen kompletten Vergleich von system.Exec() gegenüber CUxD-Exec machen und hier nicht nur eventl. Bugs/Probleme diesbzgl. auflisten wollen sondern auch mögliche Limitation (fehlende Features, etc.) die in system.Exec() existieren im Vergleich zu CUxD-Exec aufzeigen wollen.

[uwe111]

Hallo Jens,

Auch würde mich interessieren ob es irgendwelche nennenswerten Limitationen von system.Exec() gegenüber den CUxD-Exec Aufrufen gibt die eventl. beachtenswert wären. Ich möchte hier einfach mal einen kompletten Vergleich von system.Exec() gegenüber CUxD-Exec machen und hier nicht nur eventl. Bugs/Probleme diesbzgl. auflisten wollen sondern auch mögliche Limitation (fehlende Features, etc.) die in system.Exec() existieren im Vergleich zu CUxD-Exec aufzeigen wollen.

Na wenn Du hier mal nicht Äpfel mit Birnen vergleichst.

Der Ansatz vom CUxD-Exec ist halt ein ganz anderer. Bei CUxD-Exec funktioniert die Befehlsausführung abgekoppelt über einen Datenpunkt eines virtuellen Gerätes mit weiterer Funktionalität und bei System.Exec wird der Befehl m.E. direkt im Script ausgeführt.
So handelt es sich beim CUxD-Exec eher um eine Erweiterung, als einen Ersatz. Ich denke für beides gibt es Anwendungen, falls System.Exec jetzt stabil laufen sollte.

Viele Grüße

Uwe

[peissl.at]

Hallo,

ich hatte vor der Umstellung auf CUxD reproduzierbare Probleme mit dem system.exec der CCU.
Ich verwendete system.exec zum Versenden von Push-Nachrichten. Das Versenden einzelner Nachrichten ging relativ gut. Aber das Versenden von mehreren Nachrichten gleichzeitig führte dazu, dass irgendwann (vielleicht nach 50 Nachrichten) keine Programme mehr ausgeführt wurden.
Ich hab mir das so erklärt, dass das Aufrufen eines system.exec-Befehls, während ein anderer noch lief, irgendwelche Rückstände im System verursacht.
Bei genügend Rückständen kann die CCU keine Programme mehr ausführen.

Sonnige Grüße!
Robert

[BadenPower]

Aber das Versenden von mehreren Nachrichten gleichzeitig führte dazu, dass irgendwann (vielleicht nach 50 Nachrichten) keine Programme mehr ausgeführt wurden.

Wie wurden die Nachrichten denn gleichzeitig verschickt?

Wenn möglich bitte das entsprechende Skript und Programm posten und beschreiben wie das Programm getriggert wurde.

Ohne diiese Informationen ist es nicht reproduzierbar.
.

[peissl.at]

Hallo,

Du legst einfach zwei Programme an. In jedem der Programme verwendest Du im Script einen system.exec-Befehl (zB: zum Versenden von Push-Nachrichten)
wget -q -O /dev/null '"#url#"'
Dann stellst Du sicher, dass beide Programme zugleich ausgelöst werden. (zB: beide enthalten den selben WENN-Teil)
Nach gefühlten 50 Programmstarts, wurden bei mir dann keine Programme mehr ausgeführt.

Umstellung auf CUxD so um das Jahr 2013 hat das dann Problem gelöst.

Sonnige Grüße!
Robert

PS: Ich kann auch das CCU-Timerproblem reproduzieren, aber das ist eine andere Geschichte...

[BadenPower]

Dann stellst Du sicher, dass beide Programme zugleich ausgelöst werden. (zB: beide enthalten den selben WENN-Teil)
Nach gefühlten 50 Programmstarts, wurden bei mir dann keine Programme mehr ausgeführt.

Habe ich gerade getestet mit 200 wget-Aufrufen.
Der Fehler ist so nicht reproduzierbar. Die CCU führt die 200 Anweisungen komplett durch und werkelt danach dann ganz normal weiter.

Kann es sein, dass Du nur gemeint hast, dass die Programme nicht mehr gestartet werden?
Du mußt natürlich beachten, dass wenn Du ein/zwei Programme 50 mal hintereinander triggerst, erst diese 50 Programme und Skripte nacheinander vollständig abgearbeitet werden bis das nächste Programm/Skript überhaupt eine weitere Aktion ausführt.

Wenn jetzt zum Beispiel ein einziger wget-Aufruf 1 Minute benötigt, dann geht fast 1 Stunde nichts mehr Anderes auf der CCU. Also die CCU ist für eine Stunde quasi lahmgelegt.

PS: Ich kann auch das CCU-Timerproblem reproduzieren, aber das ist eine andere Geschichte...

Dann her damit.
.

[jmaus]

PS: Ich kann auch das CCU-Timerproblem reproduzieren, aber das ist eine andere Geschichte...

Dann her damit.

Nur weil eine langsame CCU2 nicht regelmäßig in das CCU-Timerproblem rennt heisst das noch lange nicht das das Problem auch nicht existiert (hat). Schau dir einfach dazu mal folgendes changelog an:

https://github.com/eq-3/occu/tree/maste ... WebUI-Beta

Unter RaspberryMatic passiert sowas einfach häufiger weil dort die Ressourcen nicht so knapp sind und die CPU das multithreading das in ReGaHss steckt dann besser ausnutzen kann und es zu race conditions kommt. Gottseidank repariert das die ReGaHss Beta version die ich dort referenziert habe aber.