FHEM Forum

Hallo!

Ich habe ein dummes Anfängerproblem: qx liefert bei mir nichts zurück.

Wenn ich in der FHEM Konsole { return qx(ls) } eingebe, bekomme ich nichts zurück. Oder auch { return `pwd` } liefert nichts. Es liegt also nicht an der Schreibweise...

Das Problem ist übrigens beim Aufruf von ping in 99_myUtils aufgetaucht:
my $ret = qx(ping -c 1 -q google.com);
if ($ret =~ /1 received/)
liefert Use of uninitialized value $ret in pattern match (m//) ...

Ich konnte es auf den fehlende Rückgabewert von qx rückverfolgen. Habt ihr vielleicht Idee woran das liegen könnte?

lg; Piotr

Bei mir funktioniert Dein Code völlig problemlos.

Sowohl das hier:


sub test {
my $ret = qx(ping -c 1 -q google.com);
if ($ret =~ /1 received/) { return "gefunden" };
}


als auch

{qx(ls)}

als auch

{return qx(ls)}

in der FHEM Befehlszeile liefern bei mir die erwarteten Ergebnisse.

Stehen denn irgendwelche Hinweis im Logfile, warum es nicht funktionieren könnte?

Danke fürs nachschauen!

Ich habe

{ my $ret = qx(ping -c 1 -q google.com);; if ($ret =~ /1 received/) { return "gefunden" };; }

ausprobiert und mit verbose=5 habe ich in der log-Datei:

PERL WARNING: Use of uninitialized value $ret in pattern match (m//) at (eval 664536) line 1.

bekommen. Also tatsächlich liefert qx nichts. Ich habe inzwischen perl upgrade bemacht (buster auf R PI, perl auf 5.28) - brachte aber nichts.
Ist das vielleicht ein Rechteprobleme?

{ my $ret = qx(ping -c 1 -q google.com);; if ($ret =~ /1 received/) { return "gefunden" };; }

liefert bei mir (wie erwartet) gefunden zurück.

Hast du ping überhaupt installiert?

Zitat von: Christoph Morrison am 29 Oktober 2020, 20:29:33
Hast du ping überhaupt installiert?

wenn das die Ursache wäre, gäbe es einen entsprechenden Fehlerhinweis im Log:

2020.10.29 20:47:54 1: PERL WARNING: Can't exec "ping2": No such file or directory at ./FHEM/99_myUtils.pm line 22.

Zitat von: betateilchen am 29 Oktober 2020, 20:49:36
wenn das die Ursache wäre, gäbe es einen entsprechenden Fehlerhinweis im Log

Ich weiß, aber weißt du ob petibub uns überhaupt alle relevanten Logeinträge kopiert hat?

Zitat von: Christoph Morrison am 29 Oktober 2020, 20:29:33

Hast du ping überhaupt installiert?

Berechtigte Frage - Ja, habe ich. ping funktioniert problemlos in der Bash, ich habe auch andere Befehle ausprobiert  - in Wirklichkeit brauch ich sendEmail, das in Bash geht aber von FHEM aus nicht.

Habe noch stacktrace auf 1 und verbose auf 5 gestellt und dann

{ my $ret = qx(ping -c 1 -q google.com);; if ($ret =~ /1 received/) { return "gefunden" };; }

ausgeführt. Log:

2020.10.30 16:23:24 5: Cmd: >{ my $ret = qx(ping -c 1 -q google.com); if ($ret =~ /1 received/) { return "gefunden" }; }<
2020.10.30 16:23:24 1: PERL WARNING: Use of uninitialized value $ret in pattern match (m//) at (eval 700271) line 1.
2020.10.30 16:23:24 3: eval: { my $ret = qx(ping -c 1 -q google.com); if ($ret =~ /1 received/) { return "gefunden" }; }
2020.10.30 16:23:24 1: stacktrace:
2020.10.30 16:23:24 1:     main::__ANON__                      called by (eval 700271) (1)
2020.10.30 16:23:24 1:     (eval)                              called by fhem.pl (1135)
2020.10.30 16:23:24 1:     main::AnalyzePerlCommand            called by fhem.pl (1160)
2020.10.30 16:23:24 1:     main::AnalyzeCommand                called by fhem.pl (1089)
2020.10.30 16:23:24 1:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2678)
2020.10.30 16:23:24 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (951)
2020.10.30 16:23:24 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (578)
2020.10.30 16:23:24 1:     main::FW_Read                       called by fhem.pl (3753)
2020.10.30 16:23:24 1:     main::CallFn                        called by fhem.pl (748)


Hilft das irgendwie?

Ich habe übrigens Buster mit Touchscreen auf R Pi installiert. Hilft diese Info irgendwie?
lG; Piotr

Inzwischen weiß ich, dass es an meinem Perl oder System liegt. Denn in der Bash
perl -e "qx(ping -c 1 -q google.com);"
liefert nichts zurück.

Vielleicht habe ich irgendwie STDOUT umgebogen? Ich schaue mal was das mächtige Internet dazu sagt...  :-[

Zitat von: petibub am 30 Oktober 2020, 16:53:25
Inzwischen weiß ich, dass es an meinem Perl oder System liegt. Denn in der Bash

Code Auswählen Erweitern

perl -e "qx(ping -c 1 -q google.com);"
liefert nichts zurück.

Das ist ganz normal.

Was liefert aber
perl -e "print qx(ping -c 1 -q google.com);"?

Ansonsten, was kommt in der Log wenn Du folgendes in Fhem eingibst?
{ print qx(date) }

Zusätzliche Tests in der Console:
perl -le'use Config; print $Config{sh}'
Dann:
file /xxx/xxxx wo /xxx/xxxx das Ergebnis vom vorherigen Perl-Kommando ist

Lieber amenomade, danke dass du mir hilfst!

Zitat von: amenomade am 30 Oktober 2020, 22:49:29
Das ist ganz normal.

ah, habe jetzt auch gemerkt. Falsche Fährte...

ZitatWas liefert aber

Code Auswählen Erweitern

perl -e "print qx(ping -c 1 -q google.com);"?

Damit bekomme ich ein richtiges Ergebnis:
PING google.com (172.217.23.46) 56(84) bytes of data.

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.628/12.628/12.628/0.000 ms


Zitat
Ansonsten, was kommt in der Log wenn Du folgendes in Fhem eingibst?

Code Auswählen Erweitern

{ print qx(date) }

Dann bekomme ich leider nur:
1

ZitatZusätzliche Tests in der Console:

Code Auswählen Erweitern

perl -le'use Config; print $Config{sh}'

Da bekomme ich
/bin/sh

Und mit:
file /bin/sh
bekomme ich:
/bin/sh: symbolic link to dash
Kannst du damit etwas anfangen?
Danke!

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

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

Jetzt wäre die Frage: was kommt in der Log bei
{print qx(ping -c 1 -q google.com)} in der Kommandozeile von Fhem
Das um sicher zu stellen, dass Du nicht zwei unterschiedliche Versionen von Perl hast (eine mit User pi in der Console, und eine andere, die Fhem benutzt), die unterschiedlich reagieren.

ich geh mal Popcorn machen...

Zitat von: petibub am 31 Oktober 2020, 10:16:45
Dann bekomme ich leider nur:

Code Auswählen Erweitern

1

Im Log oder im Webfrontend angezeigt? Im Log sollte halt das Datum stehen.

Zitat von: petibub am 31 Oktober 2020, 10:16:45

Code Auswählen Erweitern

/bin/sh: symbolic link to dash
Kannst du damit etwas anfangen?

Abhängig vom OS ist das ok.

Was wird bei

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

angezeigt?

Zitat von: betateilchen am 31 Oktober 2020, 10:31:09
ich geh mal Popcorn machen...

Ich hätte gerne welches mit Karashell.

Zitat von: betateilchen am 31 Oktober 2020, 10:31:09
ich geh mal Popcorn machen...

Du kannst aber auch gerne weitere konstruktive Vorschläge machen, um das Problem zu begrenzen. Das mit mehreren Perl Installationen habe ich schon mehrmals hier gesehen, deswegen frage ich. Aber der TE freut sich bestimmt auf andere mögliche Erklärungen seines Problems.

Zitat von: amenomade am 31 Oktober 2020, 10:34:15
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.

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?

Zitat von: amenomade am 31 Oktober 2020, 10:47:30
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.

Interessant wäre vielleicht die Ausgabe von:

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

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.

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

Hatte ich durchaus gesehen.

Es nützt aber wenig, in einer shell-Konsole 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".

Dafür geht doch dann:
{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:
{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 :)

Zitat von: amenomade am 31 Oktober 2020, 10:27:46
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:

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


ZitatJetzt 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:
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


Zitat von: amenomade am 31 Oktober 2020, 11:32:26
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
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

Zitat von: betateilchen am 31 Oktober 2020, 14:05:45

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?

{use Data::Dumper;; Dumper(%ENV)}
liefert:
$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';

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:
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  ;) ).

Problem gelöst.

Zitat von: Otto123 am 31 Oktober 2020, 14:35:00
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.

Zitat von: Otto123 am 31 Oktober 2020, 14:35:00
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.

Zitat
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.

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...

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

Bin froh, dass wir das hinbekommen haben - Danke für die Hilfe!

Zitathabe ich vom Rechner dazukopiert

Wahrscheinlich mit dem user pi, oder root ... und damit eben nicht der User fhem ..


erech: ~fhem $ stat fhem.pl fhem.cfg
  File: fhem.pl
  Size: 155710    Blocks: 312        IO Block: 4096   regular file
Device: b302h/45826d Inode: 131422      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
Access: 2019-01-28 17:50:00.000000000 +0100
Modify: 2019-01-28 07:57:31.000000000 +0100
Change: 2020-10-31 16:12:39.475056437 +0100
Birth: -
  File: fhem.cfg
  Size: 2166      Blocks: 8          IO Block: 4096   regular file
Device: b302h/45826d Inode: 128380      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
Access: 2019-01-28 18:09:03.839999791 +0100
Modify: 2019-08-13 14:42:43.608553336 +0200
Change: 2020-10-31 16:12:39.475056437 +0100
Birth: -


→ { my $ret = qx(ping -c 1 -q google.com);; if ($ret =~ /1 received/) { return "gefunden" };; }
→ gefunden

Verstehe es nicht.

Danke für eure Erklärung, das bestätigt wenigstens meine Gedanken dazu :)

Die Lösung ist toll - die Ursache verstehe ich auch noch nicht ganz.  ::)  Welches Recht muss man wegnehmen damit dieser Fehler auftritt?
Ein Recht am Pfad (HomeDir) /opt/fhem an sich? 

Ich darf Ihn Zitieren:

Zitatsudo chown -R fhem:dialout /opt/fhem/

Ich währe aber niemals auf die Idee gekommen, das ein falscher Benutzer so etwas "ausrichten" kann.

Kleiner Hinweis am Rande:
Ob die Gruppe "dialout" richtig ist, steht auf einem anderen Blatt. Bei mir auf den Systemen jedenfalls ist eigentlich die Gruppe auch fhem ...

Ich glaube nicht, dass das Problem wirklich ein Berechtigungsproblem war. Der TE hat nicht nur die permissions zurückgesetzt (was nicht weh tun kann ;) ), sondern auch Fhem komplett neu gestartet.

Zitat von: betateilchen am 31 Oktober 2020, 11:56:08
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.

Deswegen hätte es keinen Sinn, $? zu testen. Aber $! schon. Und siehe da:

Zitat
Zitat von: amenomade am Heute um 11:32:26

    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  :-\.

Dies kommt wenn das System nicht genug Speicher hat, um das Kommando zu spawnen. Und natürlich in diesem Fall ergibt es undef in Perl.

Ausserdem muss man sagen: qx() sowie auch system(), starten keine Shell wenn sie es nicht brauchen (sprich wenn keine Shell Metacharacters zu interpretieren sind -  ich dachte es wäre nur wenn überhaupt kein Parameter, deswegen wollte ich mit date statt ping testen, aber mittlerweile habe ich gelesen ;) ), sondern sendet direkt den Befehl an execvp.

Und ein möglicher return code von execvp ist:
ENOMEM
    There's insufficient memory available to create the new process.

EDIT: was mich irritiert, ist dass er keine Hinweise wie "Can't allocate memory" in der Fhem-Log hatte. Aber vielleicht liegt es an der Art des forks, was qx macht.

@petibub:
Such mal in deinem FHEM-Log ob du da FORK-Meldungen hast.

Dazu machst du auf dem Terminal

grep -c CANNOT_FORK  <hier setzt du deinen Logfile ein, ohne die spitzen Klammern>

Bei mir z.B.:

grep -c CANNOT_FORK /opt/fhem/log/fhem.log

Zitat von: Christoph Morrison am 31 Oktober 2020, 19:51:46
@petibub:
Such mal in deinem FHEM-Log ob du da FORK-Meldungen hast.

Dazu machst du auf dem Terminal

Code Auswählen Erweitern

grep -c CANNOT_FORK  <hier setzt du deinen Logfile ein, ohne die spitzen Klammern>

Bei mir z.B.:

Code Auswählen Erweitern

grep -c CANNOT_FORK /opt/fhem/log/fhem.log

Meiner Meinung nach, wird es nur etwas bringen, wenn Fhem selbst die Notwendigkeit hatte, fhem.pl (also, sich selbst) zu forken, und es nicht geschafft hat. Die Fehlermeldung vom qx fork kommt wahrsecheinlich nicht so weit, dass die Fhem Log sie sieht. Aber die Frage ist interessant... mal sehen, was petibub liefert.

Stimmt, das mit dem reboot hatte ich überlesen ...

Zitat von: amenomade am 31 Oktober 2020, 20:02:39
Meiner Meinung nach, wird es nur etwas bringen, wenn Fhem selbst die Notwendigkeit hatte, fhem.pl (also, sich selbst) zu forken, und es nicht geschafft hat. Die Fehlermeldung vom qx fork kommt wahrsecheinlich nicht so weit, dass die Fhem Log sie sieht. Aber die Frage ist interessant... mal sehen, was petibub liefert.

Das liefert bei mir 0, d.h. nichts gefunden.