Edomi EXEC verhält sich anders als PHP-Datei im Browser

[MrIcemanLE]

Hallo Zusammen,

ich habe ein Problem mit der exec()-Funktion im EXEC Bereich eines LBS. Ich versuche den return code des aufgerufenen Programms auszuwerten. Das merkwürdige ist, dass ich im LBS eine 1 bekomme und in einer PHP-Datei im www-Verzeichnis von Edomi eine 0. Hier die Codeschnipsel:

LBS EXEC-Teil:

if (json_last_error() === JSON_ERROR_NONE) 
        {
            $command = $vc_pfad.'vclient -h '.$ip.':'.$port.' -f '.$pfad_commands.' -t '.$pfad_template.' -o '.$pfad_status.' 2>&1';
            unset($output);
            unset($returnCode);
            logging($id, "Command: $command");
            exec($command, $output, $returnCode);
            if ($returnCode != 0) 
            {
                logging($id, "FEHLER bei Kommando: $command", $output, 2);
                logging($id, "vclient - Rückgabewert $returnCode", $output, 2);
            }
            else
            {
                logic_setOutput($id, 2, file_get_contents($pfad_status));
                logging($id, "Ausgabe JSON String: ".file_get_contents($pfad_status), 5);
            }
            
        }
        else
        {
            logging($id, "FEHLER - Ungültiger JSON-String", 2);
            logging($id, json_last_error_msg(), 2);
        } 

Hier meine Test-Datei aus dem www-Verzeichnis:

<?php
$cmd = "/usr/local/edomi/main/vcontrol/vclient -h localhost:3002 -f /usr/local/edomi/main/vcontrol/template/2190-vc-commands.txt -t /usr/local/edomi/main/vcontrol/template/2190-vc-status.tmpl -o /usr/local/edomi/main/vcontrol/template/2190-vc-status.json 2>&1";

exec($cmd,$output, $returnCode);

print( 'output:');
var_dump($output);

print( "<br>");
print( "<br>");

print( 'returnCode:');
var_dump($returnCode);

print( "<br>");
print( "<br>");

if ($returnCode != 0)
    echo "!= 0";
else
    echo "== 0";

Der LBS erzeugt Logeinträge, also ist $returnCode != 0 und die Testdatei gibt aus, dass $returnCode == 0 ist.

Hat jemand eine Idee? Meine letzte Vermutung ist jetzt, dass sich das Programm anders verhält, wenn es aus dem EXEC-Bereich aufgerufen wird. Vielleicht ein Rechteproblem?

[vento66]

Schau doch mal, ob die 0 als String ankommt, also einfach mal Testweise   if ($returnCode == "0"){......}  Im Moment prüfst Du ja nur ob er nicht 0 ist.

[jonofe]

Der Webserver wird im Kontext der "apache" Users ausgeführt. EDOMI führt die EXEC Skripte im root Kontext aus.

Warum führst du das Skript nicht manuell in einer Shell aus, wenn du die Ausgabe sehen willst?

php <Dein_Skript_Name.php>

Was steht denn in $output drin, wenn du es über edomi aufrufst?

[MrIcemanLE]

Laut dem Log-File ist der Rückgabewert 1 bei Aufruf im EXEC-Teil und 0 bei Aufruf über die Konsole bzw. den Browser.
$output ist leer (sowohl im LBS-Log als auch im Browser), da das Programm keinen Output liefert, sondern die ermittelten Werte in eine Ausgabedatei schreibt. Diese Ausgabedatei wird durch den LBS auch nicht aktualisiert. Daher scheint der Rückgabewert 1 berechtigt zu sein. Wenn ich das ganze über die Test-Datei laufen lasse, wird auch die Ausgabedatei aktualisiert und es folgt der Rückgabewert 0.

vento66 die 0 kommt als int. Das sehe ich, wenn ich meine Testdatei im Browser aufrufe und ein var_dump() mache. Auf GitHub habe ich im Source-Code auch gesehen, dass die main() ein int liefert. Das Merkwürdige ist ja, das im LBS-Kontext eine 1 kommt (siehe Log) und mit der Testdatei eine 0. Es liegt also nicht am Rückgabewert selbst, sondern das Programm vclient verhält sich unterschiedlich, ob es aus dem LBS aufgerufen wird oder nicht.

Ausgabe im Log-File:

2019-06-13 07:55:10    461251    28772    err    EXE19001530 [v1.10]: FEHLER bei Kommando: /usr/local/edomi/main/vcontrol/vclient -h localhost:3002 -f /usr/local/edomi/main/vcontrol/template/2190-vc-commands.txt -t /usr/local/edomi/main/vcontrol/template/2190-vc-status.tmpl -o /usr/local/edomi/main/vcontrol/template/2190-vc-status.json 2>&1
2019-06-13 07:55:10    461762    28772    err    EXE19001530 [v1.10]: ================ ARRAY/OBJECT START ================
2019-06-13 07:55:10    461899    28772    err    EXE19001530 [v1.10]: ================ ARRAY/OBJECT END ================
2019-06-13 07:55:10    463551    28772    err    EXE19001530 [v1.10]: vclient - [COLOR=#B22222]Rückgabewert 1[/COLOR]
2019-06-13 07:55:10    463795    28772    err    EXE19001530 [v1.10]: ================ ARRAY/OBJECT START ================
2019-06-13 07:55:10    463922    28772    err    EXE19001530 [v1.10]: ================ ARRAY/OBJECT END ================

Ausgabe bei Aufruf als root über die Konsole:

# php vcontrol-test.php

output:array(0) {

}

<br><br>[COLOR=#B22222]returnCode:int(0)[/COLOR]

<br><br>== 0

@

[jonofe]

Wie sieht denn der Log-Eintrag in EDOMI des Commands aus?
Hast du dieses Command nochmal geprüft, ob es wirklich dasselbe ist, wie in deinem console skript?
Warum hast du das 2>&1 drin? Damit würde der Fehler dann auch in das File geschrieben, wenn ich das richtig verstehe.

[MrIcemanLE]

Wie sieht denn der Log-Eintrag in EDOMI des Commands aus?

Das $command wird ja in das Log-File geschrieben (siehe oben): Fehler bei $command. Von dort (Log) habe ich das zusammengebaute Command kopiert und in meine Testdatei eingefügt.

Hast du dieses Command nochmal geprüft, ob es wirklich dasselbe ist, wie in deinem console skript?

Ja, die Commands sind identisch. Das, was im Log-File von EDOMI steht, zu dem, welches ich in meiner Testdatei habe.

Warum hast du das 2>&1 drin?

Ehrlich gesagt, stammt der LBS nicht von mir. Habe da nur einen Anteil dran, da ich den ursprünglichen LBS gebaut habe und murelli146 den LBS weiterentwickelt hat.

Soweit ich das verstehe wird mit 2>$1 der stderr (2) auf den stdout (1) umgeleitet. D.h. falls die Anwendung einen Fehler wirft, sollte dieser in $output landen. Der Return-Code bleibt davon unberührt.

[MrIcemanLE]

Hab das Problem gefunden (glaube ich zumindest), verstehe es aber nicht zu 100%. Der zugehörige Dämon (vcontrold) lief mehrfach unter dem root-User. Der Code des LBS hat jetzt versucht den Dämon zu starten, ohne Erfolg. Dadurch liefert der vclient auch einen Fehler zurück. Bist du dir sicher, dass EXEC teil als root ausgeführt wird? Denn der root-User hatte den Dämon ja laufen, daher war die Abfrage erfolgreich.

[root@Edomi vcontrol]# pgrep -u root vcontrold
1782
.. (16 weitere)
29575
[root@Edomi vcontrol]# pgrep -u apache vcontrold
[root@Edomi vcontrol]# killall -s SIGKILL vcontrold
[root@Edomi vcontrol]# pgrep -u root vcontrold
​​​​​​​(keine Ausgabe)

Möglicherweise ist das killall command in dem LBS nicht richtig formuliert, wodurch sich die Instanzen des Dämon ansammeln:

killall -SIGTERM vcontrold

mein Vorschlag:

killall -s SIGKILL vcontrold

[jonofe]

Ich würde das 2>&1 mal rausnehmen.

Du könntest auch noch mal versuchen dem Kommando ein "bash -c" vorauszustellen, damit erzwungen wird, dass das Kommando in einer bash Shell ausgeführt wird. Ggf. wird ansonsten eine sh Shell verwendet. Ich glaube dennoch nicht, dass dies die Ursache sein sollte.