PHP Skript direkt über PHP Binary im Hintergrund arbeiten lassen

[peaceman]

Hallo Forenuser!

Ich habe folgendes Problem: Ich möchte per PHP einen Backgroundprozess (zur Videokonvertierung)auf der Linux Shell starten. Da jedoch einige Aufgaben erst nach abgeschlossener Konvertierung stattfinden können (zB Thumbs aus konvertierter Datei erstellen, Originalvideo löschen), möchte ich, dass ein PHP-Skript im Hintergrund aufgerufen wird, das seinerseits nacheinander die nötigen Prozesse aufruft, der Betrachter soll jedoch schon auf die nächsten Seite gelangen. Hier sitzt der Knackpunkt, da die Binaries "nicht gefunden" werden. Genug der Vorrede, nun ein paar Veranschaulichungen. BTW, ich benutze Suse 10.2 mit Apache 2.2.0 und "PHP 5.1.2 with Suhosin-Patch 0.9.6 (cli) ".

Folgendes läuft auf meinem Entwicklungs- und auf dem Produktivsystem einwandfrei:
(es werden nur die essentiellen Codestückchen präsentiert)

  
exec("/usr/bin/mencoder [argumente]");  
mach_thumbnails($video_neu);  
header("Location:weiter.php");  

-> mencoder-binary wird gefunden, konvertierung wird normal ausgeführt, php "wartet" natürlich, bis die konvertierung fertig ist, thumbs werden generiert, user gelangt auf die nächste seite.

  
exec("/usr/bin/mencoder [argumente] &> /dev/null &");  
mach_thumbnails($video_neu);  
header("Location:weiter.php");  

-> binary wird gefunden, konvertierung wird im hintergrund ausgeführt, thumbs werden nich erstellt, da ja die neue datei benötigt wird, user gelangt einfach auf die neue seite.

Will ich deshalb jedoch ein gesamtes Skript über die PHP-CLI laufen lassen steigt das Produktivsystem aus:
3)

  
exec("/usr/bin/php5 /srv/var/www/htdocs/encode.php &> /dev/null &");  
header("Location:weiter.php");  

mit zugehöriger encode.php:

  
if (exec("/usr/bin/mencoder [argumente] &> /dev/null &"))  
{ mach_thumbnails($video_neu); }  

-> Das Video wird ('nur') auf dem Produktivsystem nicht konvertiert. Lenke ich die Ausgabe in eine Datei um erhalte ich
sh: /mencoder: No such file or directory

auch ein einfaches "ls" lässt sich hier nicht ausführen (mit gleicher Fehlermeldung). Mit relativen und absoluten Pfaden hab ich schon wild herumprobiert, open_basedir auf "no value" gesetzt. Das Script wird ja angeschossen, hat aber irgendwie keine Rechte die Binaries auszuführen... kann es am Suhosin Patch liegen, dass gewisse "Ausführungstiefen" nicht mehr gestattet sind? Die Systeme sind sonst weitgehen identisch, es werden die gleichen Extensions geladen, etc. PHP ist bizarrerweise auf BEIDEN systemen mit --disable-cli kompiliert, was aber das Entwicklungssystem nicht davon abhält trotzdem seine Arbeit zu verrichten...? Mhm.

Wo könnte ich noch nachforschen, bzw. hat jemand schoneinmal ähnliche Erfahrungen gemacht? Falls noch irgendwie Code oder Infos zum besseren Verständnis fehlen - wird gern nachgereicht.

regards,
peaceman

[Johannes Zeller]

Hallo peaceman,

sh: /mencoder: No such file or directory

Die Fehlermeldung irritiert mich, ich hätte erwartet, dass höchstens /usr/bin/mencoder als nicht gefundene Datei ausgegeben wird.

Hast du Shell-Zugang auf dem Produktiv-Server? Wenn ja, hast du mal ausprobiert, die encode.php auf der Konsole auszuführen?

Guck auch mal nach, ob unterschiedliche php.inis verwendet werden und wo die sich unterscheiden.

Schöne Grüße,

Johannes

[peaceman]

Hallo Johannes,

Hast du Shell-Zugang auf dem Produktiv-Server? Wenn ja, hast du mal ausprobiert, die encode.php auf der Konsole auszuführen?

Ja, habe ich gerade gecheckt: Es erscheint auch der gleiche Fehler:
sh: /mencoder: No such file or directory

Rufe ich per Hand "mencoder" auf - relativ wie absolut - findet er das Binary ohne Probleme.

Rufe ich wiederum /usr/bin/php5 -r "exec('mencoder');"
gibts wieder "No such file." Eigentlich verwunderlich, da ja die exec() commands in den PHPs einwandfrei ausgeführt werden.

/usr/bin/php5 -r "exec('hello world');" funktioniert auch, sodass die cli-option wohl auf jeden Fall enabled ist.

Auch beim Environment-Path müsste ich mit   /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin eigentlich auf der sicheren Seite sein.

Gibt es denn noch irgendwo PATH-Geschichten, die für die PHP-Binary interessant sind?

Guck auch mal nach, ob unterschiedliche php.inis verwendet werden und wo die sich unterscheiden.

Nehme ich nochmal genauer in Augenschein... auf den ersten Blick ist aber ausser triviale Unterschiede wie ERROR_REPORTING nichts bizarres auszumachen.

regards,

peaceman

[Chris]

Hallo zurück,

exec("/usr/bin/mencoder [argumente]");

Da wartet PHP jetzt solange, bis der Befehl abgearbeitet ist.
Außerdem solltest Du das Ergebnis von Exec() auch irgendwo auffangen.

Oder Du schaust Dir noch mal die UCN bei PHP an:

http://www.php.net/manual/en/function.exec.php
siehe juha at kuhazor dot idlegames dot com

$pid=exec("/usr/local/bin/php run.php > /dev/null & echo $!");

Das stand hier neulich schon einmal im Forum.

LG
Der Chris

[peaceman]

re Hallo,

exec("/usr/bin/mencoder [argumente]");

Da wartet PHP jetzt solange, bis der Befehl abgearbeitet ist.
Außerdem solltest Du das Ergebnis von Exec() auch irgendwo auffangen.

Das ist mir durchaus bewusst, daher ja die nach-und-nach Entwicklung bzw. Darstellung meines Problems:

Hier sitzt der Knackpunkt, da die Binaries "nicht gefunden" werden.
»»
Will ich deshalb ein gesamtes Skript über die PHP-CLI laufen
lassen steigt das Produktivsystem aus:
3)
exec("/usr/bin/php5 /srv/var/www/htdocs/encode.php &> /dev/null &");

Vielleicht ist der Titel des Postings etwas unglücklich gewählt, geb ich zu. :)

regards,
peaceman

[Chris]

Halloele,

"es heißt nicht umsonst Programmentwicklung und nicht Programmhinschreibung" hat mein Lehrer immer gesagt.
Irgendwie hat er da Recht gehabt.
Erst eine Skizze anfertigen, dann die Ideen auf einen Haufen werfen, langsam nach und nach 'entwickeln' und testen. Testen ist überhaupt das Schärfste. Immer die Grenzen suchen. Wenn Du selbst trotz alle Insiderkenntnisse Dein Programm nicht mehr zum Absturz bringen kannst, dann kannst Du den ersten User ranlassen. Und wette, dass der noch Fehlerquellen findet?

Das ist mir durchaus bewusst, daher ja die nach-und-nach Entwicklung bzw. Darstellung meines Problems:

Hier sitzt der Knackpunkt, da die Binaries "nicht gefunden" werden.

Vielleicht ist der Titel des Postings etwas unglücklich gewählt, geb ich zu. :)

Dann könntest Du doch nochmal Schrit für Schritt vorgehen und hier die Versuche nebst Ergebnissen posten.

1. Error-Reporting auf volle Pulle
2. Jeden Rückgabewert (landlüfig als "Fehler" tituliert) abfragen
3. Sich durch Kontrollausgaben während der Entwicklung ständig
   Überblick verschaffen.
   Ein Konstrukt, wie "if (DEBUG == 'ON') { Fehlermeldung }"
   ist dazu bestens geeignet. Dann muss man nur am Anfang des
   Scriptes die Kontante setzen und muss die Fehlermeldungen
   nicht dauernd aus- und einkommentieren
4. Erstmal schauen mit
   is_readable()
   is_executable()
   ...
   ob die Binaries überhaupt zur Verfügung stehen.

usw.

also in kleinen überschaubaren Schritten, deren Resulatate man noch vorhersehen und viele wichtiger, deuten kann.

LG
Der Chris

[Dennis]

Hi peaceman,

Worin dein Problem begraben liegt weiß ich leider nicht (möglicherweise am Suhosi-Patch?), jedoch möchte ich dir die Verwendung der Process Control Functions nahelegen, sofern du (wenn ich dich richtig verstanden habe) unter UNIX arbeitest ;-)

Viele Grüße,
  ~ Dennis.

[peaceman]

moinsen,

jedoch möchte ich dir die Verwendung der Process Control
Functions nahelegen, sofern du (wenn ich dich richtig verstanden habe) unter UNIX arbeitest ;-)

Vielen Dank für den Hinweis, werd ich mich mal eingehend mit beschäftigen.

regards,
peaceman