unzulässiger Befehl Fehlercode 127 in PHP-Exec-Funktion

7

Ich verwende diesen PHP-Code:

%Vor%

und bekomme einen Fehlercode von illegalem Befehl, dh 127 ... aber wenn ich diesen Befehl über ssh verwende funktioniert es ... weil Unrar auf dem Server installiert ist ... also kann jemand raten, warum exec das nicht macht richtige Sachen?

    
Intellex 13.01.2009, 10:58
quelle

6 Antworten

21

Versuchen Sie es mit dem direkten Pfad der Anwendung (/ usr / bin / unrar von was auch immer), es klingt wie php kann die Anwendung nicht finden.

    
AAA 13.01.2009, 11:02
quelle
7

Wenn Sie Apache und PHP chrootten, sollten Sie auch / bin / sh in die chroot-Umgebung einfügen. Andernfalls wird die Funktion exec () oder passthru () nicht richtig funktionieren und den Fehlercode 127, Datei nicht gefunden, erzeugen.

    
Rogelio Triviño 17.11.2010 07:59
quelle
4

Da dies eine Top-Antwort in Google ist, wollte ich meinen Fix teilen:

Die einfache Lösung, die ich hatte, war safe_mode in der Datei php.ini zu deaktivieren

%Vor%     
Brandon 22.05.2012 17:22
quelle
3
___ answer4202482 ___

Wenn Sie Apache und PHP chrootten, sollten Sie auch / bin / sh in die chroot-Umgebung einfügen. Andernfalls wird die Funktion exec () oder passthru () nicht richtig funktionieren und den Fehlercode 127, Datei nicht gefunden, erzeugen.

    
___ answer10706936 ___

Da dies eine Top-Antwort in Google ist, wollte ich meinen Fix teilen:

Die einfache Lösung, die ich hatte, war safe_mode in der Datei php.ini zu deaktivieren

%Vor%     
___ answer438625 ___

Versuchen Sie es mit dem direkten Pfad der Anwendung (/ usr / bin / unrar von was auch immer), es klingt wie php kann die Anwendung nicht finden.

    
___ qstnhdr ___ unzulässiger Befehl Fehlercode 127 in PHP-Exec-Funktion ___ antwort438685 ___

Danke für Ihre Antwort !!

Ich habe das versucht

%pr_e%

und jetzt gab es keinen Exit-Code zurück ... andere Befehle machen Datei .. Ich versuchte mkdir etc ..: s

    
___ qstntxt ___

Ich verwende diesen PHP-Code:

%Vor%

und bekomme einen Fehlercode von illegalem Befehl, dh 127 ... aber wenn ich diesen Befehl über ssh verwende funktioniert es ... weil Unrar auf dem Server installiert ist ... also kann jemand raten, warum exec das nicht macht richtige Sachen?

    
___ tag123php ___ PHP ist eine weit verbreitete, dynamische, objektorientierte und interpretierte Skriptsprache, die primär für die serverseitige Webentwicklung entwickelt wurde. ___ tag123exec ___ Dieses Tag verweist auf den Start eines anderen, untergeordneten Programms. Es ist nach der Familie der POSIX-Systemaufrufe benannt, deren Name mit "exec" (insbesondere "execve") beginnt, obwohl ähnliche Konzepte auch auf anderen Plattformen existieren, insbesondere wenn sie mit dem Starten eines anderen Prozesses kombiniert werden. ___ answer5430950 ___

Nur für den Fall, dass jemand anderes dieses Problem noch hat, sehen Sie sich den Beitrag hier an:

Ссылка

Quote:

  

Ich habe das Problem gefunden. Das Problem war mein Sicherheitsparanoid OpenBSD. Bei der Aktualisierung von 3.1 auf 3.2 haben sie hinzugefügt:

     
  • Apache läuft standardmäßig chroot'd. Um dies zu deaktivieren, siehe die neue Option -u.
    •   

Die Chroot hat Apache daran gehindert, auf etwas außerhalb eines Verzeichnisses zuzugreifen, also habe ich alles in das Apache-Verzeichnis einschließlich netpbm verschoben. Alles war zugänglich und ausführbar, aber ich denke, es war immer noch in einer Art "abgesicherten Modus", weil die exec () immer 127 zurückgab.

     

Wie auch immer, das Ausführen von httpd mit der Option -u ging zurück zu dem weniger sicheren Startup mit nicht chroot'd apache, was es der exec () erlaubte, wieder zu arbeiten.

    
___ answer439371 ___

ohkiee guyz danke ... und ja, es könnte einige Fehler mit $ PATH geben ... aber mit gegebenem vollständigen Pfad funktioniert es:)

%code%

    
___
Intellex 13.01.2009 11:25
quelle
1

ohkiee guyz danke ... und ja, es könnte einige Fehler mit $ PATH geben ... aber mit gegebenem vollständigen Pfad funktioniert es:)

%pr_e%

    
Intellex 13.01.2009 15:29
quelle
1

Nur für den Fall, dass jemand anderes dieses Problem noch hat, sehen Sie sich den Beitrag hier an:

Ссылка

Quote:

  

Ich habe das Problem gefunden. Das Problem war mein Sicherheitsparanoid OpenBSD. Bei der Aktualisierung von 3.1 auf 3.2 haben sie hinzugefügt:

     
  • Apache läuft standardmäßig chroot'd. Um dies zu deaktivieren, siehe die neue Option -u.
    •   

Die Chroot hat Apache daran gehindert, auf etwas außerhalb eines Verzeichnisses zuzugreifen, also habe ich alles in das Apache-Verzeichnis einschließlich netpbm verschoben. Alles war zugänglich und ausführbar, aber ich denke, es war immer noch in einer Art "abgesicherten Modus", weil die exec () immer 127 zurückgab.

     

Wie auch immer, das Ausführen von httpd mit der Option -u ging zurück zu dem weniger sicheren Startup mit nicht chroot'd apache, was es der exec () erlaubte, wieder zu arbeiten.

    
ChrisH 25.03.2011 10:00
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset super () Funktion in JAVA