system.Exec: Meiden oder nicht? – Sämtliche Programme sind tot!

[Aquaplex]

Du solltest bei den Fällen wenn deine system.Exec() aufrufe die stdout/stderr ausgaben nicht benötigen am ende des kommandostrings ein & hinzufügen ind den &stdout,&stderr als parameter weglassen dann stellst du damit sicher das das system.Exec() nicht blockierend ausgeführt wird was bei einem wget aufruf schon mal lange dauern könnte. Und wenn ein aufrufendes kommando einen timeout zulässt solltest du einen eingeben weil wenn du z.b. system.Exec(" sleep 100000"); aufrufst wirst du feststellen das diese kommando die gesamte ReGa blockieren wird, wohingegen der Aufruf system.Exec("sleep 100000 &"); die rega nicht blockieren wird und trotzdem das sleep aufgerufen wird.

Sorry, wenn ich diesen alten Thread noch mal hochhole, aber wie genau würde dies in der Syntax für einen Telegram-Push aussehen?

Bei mir gerade in Test-Verwendung (natürlich mit entsprechendem Token und Chat-ID):

Code: Alles auswählen

system.Exec("wget --no-check-certificate -q -O /dev/null 'TOKEN/sendMessage?chat_id=CHATID&parse_mode=Markdown&text='"#PushMsg.ToUTF8().UriEncode());

Ich kann da am Ende nicht einfach ein & anhängen, das ergibt Fehler. Wo sollte das platziert werden?

Und ist der SystemExec-Befehl dann mit diesem Hinweis von Jens Maus stabil nutzbar oder sollte man doch lieber auf den CuXD ausweichen?

[jp112sdl]

Ich kann da am Ende nicht einfach ein & anhängen, das ergibt Fehler.

Was denn für einen Fehler?
Du hast deinen Versuch, wie/wo du das & angehängt hast, ja leider nicht gezeigt.

Wo sollte das platziert werden?

Na am Ende...

Code: Alles auswählen

system.Exec("wget --no-check-certificate -q -O /dev/null 'TOKEN/sendMessage?chat_id=CHATID&parse_mode=Markdown&text='"#PushMsg.ToUTF8().UriEncode()#" &");

[Aquaplex]

Danke sehr, ich hatte die Anführungszeichen vergessen.

Mit diesem & am Ende wartet die CCU nicht auf die Abarbeitung des Befehls, richtig? Ist der systemExec-Befehl damit stabil nutzbar?

[cloudman88]

Ich hab curl statt wget verwendet. Sollte aber egal sein

Diese Script reagiert auf den homematic Drehschalter und schickt requests an einen esp32.
Das drehen generiert natürlich schnell mehrere Events deswegen darf da nichts blockieren.

Code: Alles auswählen

var ipaddr = dom.GetObject(ID_SYSTEM_VARIABLES).Get("blegateway").Value();

string url="curl -s --location --request GET '" + ipaddr + "/cm?cmnd=dimmer%20up%2010' -o /dev/null &";
system.Exec(url);

Ok hab gerade gesehen dass du Lösung gefunden hast.
Ja damit ist es bei mir stabil - wie gesagt der HmIP-WRCR generiert ziemlich viele Events in kurzer Zeit wenn man ihn bedient

[Aquaplex]

Kam dann die bishere "Nicht-Empfehlung" des systemExec-Befehls wegen der möglichen Blockierung, wenn man das & weglässt?

[frd030]

Kam dann die bishere "Nicht-Empfehlung" des systemExec-Befehls wegen der möglichen Blockierung, wenn man das & weglässt?

Auch! Es gab auch noch andere Probleme damit, die sind aber offenbar gelöst. Läuft jedenfalls stabil, was den Befehl an sich angeht.

Man kann aber nach wie vor die RM / CCU damit blockieren, abschießen, etc. - wenn man nicht weiß, was man tut! Es gibt kein "Sicherheitsnetz"!

Das "&" schickt Befehle in den Hintergrund und vermeidet damit erstmal "Blockierungen", aber es kann auch lauter Zombie-Prozesse erzeugen, die nie terminieren und dann irgendwann eben auch zum Problem werden können. Das "&" ist kein Allheilmittel, vor allem, wenn man die Rückmeldungen braucht!

Management Summary: SystemExec sollte mit Sorgfalt angewendet werden und die Effekte vor allem am Anfang beobachtet werden!

[Black]

die Antwort ist 2 geteilt.
system exec ist eigentlich sehr stabil, mein programm nutzt das auch intensiv. das passt.

unspassig wird das aber, wenn man externe seiten ansprechen muss, möchte, die eventuell auch mal nicht zu erreichen sind.
wenn man keine Rüclmeldung braucht, sollte mann aber auch immer ein --timeout=xxx mitgeben , man kann den prozess auch mit & dann in den Hintergrund schicken.

braucht man das Rückgabeergebnis wird es unspassig.

timeout ist auch hier ein Notnagel, hier natürlich ohne & am Ende, dafür blockiert im Ernstfall die CCU über die Zeit timeout.
ich nutze für sollche Falle die Callback Funktionalität von CUXD.

hierbei wird das Problem in 2 Programme aufgeteilt, einmal das Sendende, welche den befehl über CUXD absendet und mehr nicht
ab dem Moment ist die rega wieder frei. läuft das ins nirvana, so killt CUxD von sich aus nach Zeit t den gestarteten prozess.

für das eintreffende Ergebnis und die verarbeitung schreibt man ein zweites Programm, welches von den eingetroffenden Daten der Anfrage des 1. programmes duch CUXD getriggert wird:

prinzipiell hab ichs hier mal beschrieben:
viewtopic.php?f=65&t=45388&hilit=cuxd+callback#p454674

Black

[Aquaplex]

OK, das klingt verständlich. Dann wäre ja das Absenden einer Telegram-Nachricht mit dem & am Ende sicher, denn da wird ja keine Rückmeldung erwartet. Richtig?

Wie verhält es sich beim Abfragen von Systeminfos? Hier die Temp:

Code: Alles auswählen

string cmdline = "/usr/bin/vcgencmd measure_temp";
string stdout;
string stderr;
system.Exec(cmdline, &stdout, &stderr, "&");
stdout = stdout.Replace("temp=","");
stdout = stdout.Replace("'C","");

Oder die CCU-Last:

Code: Alles auswählen

string stdout;
system.Exec ("cat /proc/loadavg", &stdout, "&");

Wird da eine Rückmeldung erwartet und das System könnte hängen bleiben?

[dtp]

Ich mache seit 2012 alles mit dem entsprechenden CUxD-Gerät zum Ausführen von Befehlen. Nutze auch für alle meine Exec-Befehle immer dasselbe Gerät - hab also keine weiteren - und hatte noch nie Probleme damit. CUxD hat für mich den Vorteil, dass es selbst dann weiter läuft, wenn die ReGaHSS mal abgestürzt sein sollte. Allerdings bin ich mir gar nicht ganz sicher, wie das jetzt mit Delays im .State()-Befehl ist. Sprich, ob die dann sofort an CUxD weitergereicht werden und CUxD dann selbst die Verzögerung verwaltet, oder ob die ReGaHSS den Befehl erst nach der Verzögerung an CUxD weitergibt. Letzteres würde beim Absturz der ReGaHSS dann ja auch dazu führen, dass der Befehl nicht mehr von CUxD ausgeführt werden kann.

Ich sehe eigentlich keinen Vorteil in system.Exec() gegenüber CUxD, außer dem, dass man dafür halt kein Addon benötigt. Aber CUxD hat ja noch weitere Vorteile, so dass ich hierauf eh nicht verzichten möchte. Und es läuft super stabil.