Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    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:
    PHP-Code:
    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"$output2);
                    
    logging($id"vclient - Rückgabewert $returnCode"$output2);
                }
                else
                {
                    
    logic_setOutput($id2file_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($idjson_last_error_msg(), 2);
            } 
    Hier meine Test-Datei aus dem www-Verzeichnis:
    PHP-Code:
    <?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?
    Gruß
    Stefan

    #2
    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.
    Mfg Micha
    Ich sage ja nicht, das wir alle dummen Menschen loswerden müssen, aber könnten wir nicht einfach alle Warnhinweise entfernen und den Dingen ihren Lauf lassen?

    Kommentar


      #3
      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?

      Code:
      php <Dein_Skript_Name.php>
      Was steht denn in $output drin, wenn du es über edomi aufrufst?
      Zuletzt geändert von jonofe; 13.06.2019, 21:31.

      Kommentar


        #4
        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:
        Code:
        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 - Rückgabewert 1
        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:

        Code:
        # php vcontrol-test.php
        
        output:array(0) {
        
        }
        
        <br><br>returnCode:int(0)
        
        <br><br>== 0
        @
        Gruß
        Stefan

        Kommentar


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

          Kommentar


            #6
            Zitat von jonofe Beitrag anzeigen
            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.

            Zitat von jonofe Beitrag anzeigen
            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.

            Zitat von jonofe Beitrag anzeigen
            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.
            Gruß
            Stefan

            Kommentar


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

              Code:
              [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:
              Code:
              killall -SIGTERM vcontrold
              mein Vorschlag:
              Code:
              killall -s SIGKILL vcontrold
              Gruß
              Stefan

              Kommentar


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

                Kommentar

                Lädt...
                X