qx liefert nichts zurück

[betateilchen]

Du kannst aber auch gerne weitere konstruktive Vorschläge machen, um das Problem zu begrenzen.

Irgendwann ist doch mal gut mit "konstruktiven Vorschlägen", wenn vom Problembären keine Reaktion kommt und alle gestellten Rückfragen einfach ignoriert werden..

Du bist der Dritte, der hier im Thread nach Logausgaben fragt und keine Antwort bekommt. Viel Spaß weiterhin.

[amenomade]

https://forum.fhem.de/index.php/topic,115386.msg1096725.html#msg1096725
Dort gibt es eine Log Ausgabe. Und anscheinend liefert qx dabei undef.
Meinst Du denn Logausaben beim Start von Fhem? Oder grössere Ausgaben, mit auch was vor und nach dem Problem kommt?

[betateilchen]

Dort gibt es eine Log Ausgabe. Und anscheinend liefert qx dabei undef.

Dass der Aufruf von qx undef zurückliefert, ist schon seit dem allerersten Beitrag hier im Thread klar, ansonsten könnte die angegebene Fehlermeldung gar nicht auftreten.

[amenomade]

Interessant wäre vielleicht die Ausgabe von:

Code Auswählen Erweitern

{ my $ret = qx(ping -c 1 -q google.com);; return $!}

[betateilchen]

Interessant wäre auch, unter welchem User das FHEM läuft und ob damit eine Shell (zum Ausführen des Systemaufrufs) überhaupt gestartet werden kann.

qx() liefert undef zurück, wenn entweder die benötigte shell nicht gestartet oder der angegebene Befehl nicht ausgeführt werden kann.
Und wenn keine shell gestartet werden kann (was ich vermute) sollte man keine Fehlermeldung erwarten, geschweige denn ein brauchbares Ergebnis.

Das deckt sich übrigens damit, dass die zum Testen "empfohlenen" Befehle auf der Konsole durchaus sinnvolle und erwartbare Ergebnisse zurückliefern.

[Christoph Morrison]

Deshalb https://forum.fhem.de/index.php/topic,115386.msg1096898.html#msg1096898

[betateilchen]

Hatte ich durchaus gesehen.

Es nützt aber wenig, in einer shell-Konsole

Code Auswählen Erweitern

perl -le'use Config; print $Config{sh}' auszuführen, um herauszufinden, ob eine shell konfiguriert ist.
Zumal der user, der diesen Befehl manuell ausführt, im Normalfall nicht der User sein dürfte, unter dem FHEM läuft.

Und die entscheidende Frage nach %ENV ist hier - wie üblich - nach wie vor unbeantwortet. Das meinte ich beispielsweise mit "auf Rückfragen wird nicht reagiert".

[Otto123]

Dafür geht doch dann:

Code Auswählen Erweitern

{use Config;; $Config{sh}}
der liefert bei mir egal wie es für User fhem in der /etc/passwd eingetragen ist /bin/sh.

Die Shell bekommt man doch über:

Code Auswählen Erweitern

{use Data::Dumper;; Dumper(%ENV)}
gar nicht angezeigt? Oder lieg ich da daneben?

In /etc/passwd kann man ja "das login" wegkonfigurieren. Wo könnte man denn die Shell wegkonfigurieren?
Der user fhem hat ja normal /bin/false in der /ect/passwd - aber {qx()} kann doch User fhem deswegen ausführen!?

Sorry, falls ich mit meinen Fragen den Popcorn Konsum anrege

[petibub]

Ich habe vermutet, dass vielleicht etwas im dem Shell gedreht wurde, aber es scheint in Ordnung zu sein.

Code Auswählen Erweitern

{ print qx(date) }liefert ja 1 zurück. Ich habe gefragt, was in der Log dabei kommt.

Sorry, habe das nicht mitgepostet. Bei verbose=1 steht nichts in der log. Bei verbose=5 steht Folgendes:

Code Auswählen Erweitern


2020.10.31 14:15:40 5: Cmd: >{print qx(ping -c 1 -q google.com)}<
2020.10.31 14:15:40 4: WEB: /fhem&fw_id=32397&room=Unsorted&fwcsrf=csrf_507519704725493&cmd=%7Bprint+qx%28ping+-c+1+-q+google.com%29%7D / RL:1496 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate


Jetzt wäre die Frage: was kommt in der Log bei

Code Auswählen Erweitern

{print qx(ping -c 1 -q google.com)} in der Kommandozeile von Fhem

Auch hier: bei verbose=1 nichts, bei verbose=5 nur das hier:

Code Auswählen Erweitern

2020.10.31 14:20:34 4: Connection accepted from WEB_192.168.1.85_49478
2020.10.31 14:20:37 4: WEB_192.168.1.85_49474 POST /fhem&fw_id=32426&room=Unsorted&fwcsrf=csrf_507519704725493&cmd=%7Bprint+qx%28ping+-c+1+-q+google.com%29%7D; BUFLEN:0
2020.10.31 14:20:37 5: Cmd: >{print qx(ping -c 1 -q google.com)}<
2020.10.31 14:20:37 4: WEB: /fhem&fw_id=32426&room=Unsorted&fwcsrf=csrf_507519704725493&cmd=%7Bprint+qx%28ping+-c+1+-q+google.com%29%7D / RL:1496 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2020.10.31 14:20:37 4: Connection accepted from WEB_192.168.1.85_49479


Interessant wäre vielleicht die Ausgabe von:

Code Auswählen Erweitern

{ my $ret = qx(ping -c 1 -q google.com);; return $!}

Das liefert "Cannot allocate memory". Das ist was neues  . Und Log sagt

Code Auswählen Erweitern

2020.10.31 14:28:28 4: WEB_192.168.1.85_49552 POST /fhem&fw_id=30807&fwcsrf=csrf_507519704725493&cmd=%7B+my+%24ret+%3D+qx%28ping+-c+1+-q+google.com%29%3B%3B+return+%24%21%7D; BUFLEN:0
2020.10.31 14:28:28 5: Cmd: >{ my $ret = qx(ping -c 1 -q google.com); return $!}<
2020.10.31 14:28:28 4: WEB: /fhem&fw_id=30807&fwcsrf=csrf_507519704725493&cmd=%7B+my+%24ret+%3D+qx%28ping+-c+1+-q+google.com%29%3B%3B+return+%24%21%7D / RL:1500 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

Und die entscheidende Frage nach %ENV ist hier - wie üblich - nach wie vor unbeantwortet. Das meinte ich beispielsweise mit "auf Rückfragen wird nicht reagiert".

Das tut mir leid. Ich finde es toll, dass ihr mir helft - bin halt nicht so schnell.
Und das mit der Log habe ich übersehen - weil dort einfach nichts steht. Außer ich stelle auf verbose=5, dann halt der Aufruf (siehe oben). Während du Popcorn genießt, hast du Ideen, was ich noch probieren könnte?

Code Auswählen Erweitern

{use Data::Dumper;; Dumper(%ENV)}
liefert:

Code Auswählen Erweitern

$VAR1 = 'USER';
$VAR2 = 'fhem';
$VAR3 = 'PATH';
$VAR4 = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin';
$VAR5 = 'LOGNAME';
$VAR6 = 'fhem';
$VAR7 = 'HOME';
$VAR8 = '/opt/fhem';
$VAR9 = 'INVOCATION_ID';
$VAR10 = '61bd9c1cfa3e40dbbb0f9d5905611e8b';
$VAR11 = 'LANGUAGE';
$VAR12 = 'de_AT.UTF-8';
$VAR13 = 'JOURNAL_STREAM';
$VAR14 = '8:695247';
$VAR15 = 'LANG';
$VAR16 = 'de_AT.UTF-8';

[petibub]

Es funktioniert - der Hinweis, dass FHEM die Shell nicht starten kann, war entscheidend. Ich habe darauf den FHEM Prozess gestoppt und die Rechte nochmal gesetzt:

Code Auswählen Erweitern

sudo chown -R fhem:dialout /opt/fhem/ .
Nach dem Neustart läuft wieder qx. Uff!

Danke euch allen für die Hilfe - jetzt gibt es ein Stamperl (zum Popcorn  ).

[petibub]

Problem gelöst.

[betateilchen]

Der user fhem hat ja normal /bin/false in der /ect/passwd - aber {qx()} kann doch User fhem deswegen ausführen!?

Ja kann er. Es ist ein weitverbreiteter Irrtum, zu glauben, dass /bin/false etwas verhindern würde.

Ich versuche mal eine vereinfachte Beschreibung:

/bin/false ist ein Linux Befehl, der bei einem interaktiven Loginversuch an der console ausgeführt wird und grundsätzlich den Return-Code für einen Fehler zurückliefert. Deshalb sieht der User nach einem Loginversuch immer wieder sofort den login-Prompt.

(/bin/login) -> übernimmt die Benutzerauthentifizierung und startet bei erfolgreicher Identifikation das Kommando, das in (/etc/passwd) steht.

Steht dort (/bin/bash), wird die Shell gestartet und nach deren erfolgreichem Start (/bin/login) beendet.
Steht dort (/bin/false), bekommt (/bin/login) einen Fehlercode zurück und durchläuft die Anmeldeschleife erneut.


Für das Ausführen von qx() erfolgt aber kein interaktiver Login.

[Christoph Morrison]

Die Shell bekommt man doch über:

Code Auswählen Erweitern

{use Data::Dumper;; Dumper(%ENV)}
gar nicht angezeigt? Oder lieg ich da daneben?

Ich wollte wissen welcher PATH gesetzt wird und welcher User konfiguriert ist. Meine Vermutung war, dass irgendwas in ENV umgedröselt wurde, das hatten wir ja in letzter Zeit häufiger mal mit INC.

Ich stelle mir dann direkt mal die Frage: Wie kann es dazu kommen, dass petibub dem User fhem Dateien weggenommen hat? Kann das wieder passieren? Wäre gut gewesen zu wissen, wem die Dateien gehört haben, als es nicht ging. @betateilchen: Deshalb finde ich es auch gut, wenn man so eine Untersuchung Schritt für Schritt macht, auch wenn es länger dauert. Ist ja schön wenn man eine Lösung hat, aber verstanden habe ich das Problem deshalb noch nicht wirklich.

Und ich muss erstmal in mich gehen um mir klar zu werden, warum das ein Problem mit qx sein kann.

Der user fhem hat ja normal /bin/false in der /ect/passwd - aber {qx()} kann doch User fhem deswegen ausführen!?

Die Loginshell hat nix mit der Shell zu tun, die man ausführen kann, wenn man schon eingeloggt ist. Also ja, kann er. Er kann sogar irgendeine andere als die konfigurierte Login-Shell starten, aber nicht beim Login.

Nachtrag: betateilchen hat das ja schon geklärt.

[petibub]

Meine SD Karte ist gecrashed und ich habe ein Backup vom letzten Jahr verwendet (habe vergessen Backup über cron einzurichten). Die neuesten Konfigurationsdateien (fhem.cfg; ein paar icons, und 99_myUtils.pm) habe ich vom Rechner dazukopiert - vielleicht ist da etwas mit den Rechten daneben gegangen...

[Christoph Morrison]

Ah siehst du, das wäre eine wichtige Info gewesen