[gelöst] Shell Befehl qx() non-blocking ausführen?

Begonnen von FHEMAN, 09 November 2016, 22:54:11

Vorheriges Thema - Nächstes Thema

justme1968

was genau versprichst du dir davon?

für jedes kommando forkst du fhem, startest noch mal ein fhem das dann das ursprüngliche kommando wieder zurück an den haupt prozess gibt und diesen dort ausführt.

kurz:
- wenn das kommando blockiert, blockiert es immer noch
- du hast zwei zusätzliche fhem prozesse als overhead

ich weiss nicht was du dir davon versprichst, aber es gibt kein problem das sich auf diese weise lösen lässt. ausser du hast ein system das sich langweilt und beschäftig werden muss.

entschuldige, aber so ist das kompletter blödsinn.

wenn das ganze überhaupt sinn haben soll musst du das langsame kommando im kontext des ersten geforkten prozesses ausführen und nur das ergebniss zurück liefern. ob das generell möglich ist bezweifle ich. bzw. es wird deutlich komplizierter und ist nicht ohne eingriff in die fhem innereien möglich. schau dir den sandbox vorschlag im developer bereich an. da ist aber noch viel dran zu machen damit es problemlos und für alle fälle funktioniert.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

FHEMAN

Ich denke, mit /opt/fhem/fhem.pl 7072 '$command' blockiere ich FHEM nicht?
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

justme1968

wenn du damit einen wert zurück gibst nicht. wenn du das komplette kommando zurück gibst und im haupt prozess ausführst gibt es keinen unterschied zum gleich dort ausführen.

schau dir noch mal die grundlagen und den kontrollfluss an. das was du machst ist komplett sinnlos.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Bensen9

Auch auf die Gefahr das hier keiner antwortet schreib ich mal meine Frage ... eigentlich wollte ich das gleiche wie FHEMAN und einfach ein Script nicht blockierend aus FHEM aufrufen. Nach Stunden suchen bin ich hier gelandet und dachte ich nehme die Lösung von CoolTux bis ich gelesen habe was Rudolf schreibt:

Zitat von: rudolfkoenig am 20 November 2016, 08:23:10
Das gibt es seit 10 Jahren (d.h. von Anfang an), indem man ein Befehl mit "" ausfuehrt (Siehe auch http://fhem.de/commandref.html#command). Falls man Rueckgabewerte auswerten will, dann packt man das Parsen/Auswerten in einem Shellskript, der die Aktionen in fhem per "perl fhem.pl localhost:7072 'set myDummy Value'" bzw. Vergleichbares ausloest. Scheinbar haben aber die meisten Angst von Shellskripten, oder meinen, das waere unordentlich, jedenfalls wird diese Methode sehr selten eingesetzt.

Falls man sowas in der Schleife braucht, dann gehoert das externe Programm als Daemon (Windows Benutzer sagen Service dazu), den man z.Bsp. per HTTP abfragen kann, und fuer die HTTP-Abfrage gibt es HTTPMOD.

Wenn ich das richtig verstehe dann sollte das einfach mit "path/script.sh" (mit " eingegeben in die FHEM commando Zeile) gehen?
Ich brauch keine Antwort vom Script bzw. kann ich das gut über telnet lösen. Nur bleibt bei mir FHEM immer stecken. Selbst wenn ich sowas einfaches mache wie "ls". Die Ausgabe von "ls" steht dann im Log aber erst nach Neustart (killall perl, perl fhem.pl fhem.cfg).

Was mach ich falsch? Könnt ihr mir helfen.

LG Ben


Bensen9

Nachtrag ... mein FHEM läuft auf OSX ...

bei meiner zweiten FHEM Instanz die ich auf einem PasPi W habe geht das "ls" ... keine Ahnung warum.

Bensen9

Das hat mir natürlich keine Ruhe gelassen und ich kam auf die Idee mein config systematisch zu halbieren und konnte tatsächlich ein Modul identifizieren welches den Fehler verursacht.

Ich habe SMARTMON laufen für meine view Festplatten. Wenn ich das Modul aus meiner config nehme geht alls. "sh" und auch mein Script laufen wunderbar ...

Ich schreib morgen mal dem SMARTMON Entwickler ... vielleicht kann der helfen

MadMax-FHEM

Ich hab zwar kein OSX sondern laufe auf einem PI...
...aber habe auch das SMARTMON-Modul im Einsatz (2x "remote-Platte", also ssh) und bei mir gehen Aufrufe mittels "irgendwas.sh" (rufe einige per at zyklisch auf)...

Aber ich bin grad dabei SMARTMON auf non-Blocking umzubauen (bzw. habe ich es grad fertig :)  ), werde das auch mal im SMARTMON-Thread vorstellen...

Weil so eine SMARTMON-Abfrage (per ssh) schon mal auch gerne bis zu 6s dauern kann, wenn die Platte "schläft"...

Aber ich bin gespannt, ob es tatsächlich einen "Zusammenhang" mit SMARTMON und "irgendwas.sh"-Aufrufen (auf OSX)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Bensen9

Danke MadMax,

Bin auch gespannt ... vielleicht brauch ich auch nur ein update des Moduls.

Non blocking wäre auch für micht gut. Wie hast du das gemacht?

MadMax-FHEM

Naja die Implementierung auf non-Blocking "umgestellt" ;)

https://wiki.fhem.de/wiki/Blocking_Call

Ist aber etwas viel "Umbau" um das hier einfach zu erläutern...

Ich werde im anderen Thread einfach mal anbieten das zu übernehmen...
Also hier: https://forum.fhem.de/index.php/topic,30491.msg231098.html#msg231098
(aber erst morgen oder so / will noch ein wenig testen und auch noch mal über den Code schauen bevor ich das anbiete/poste)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Bensen9

Klingt gut ich lese einfach mit :-).

Update hat nix gebracht - Schreib jetzt mal Hexenmeister vielleicht kann der helfen.

Gruss, Ben