Problem - Wovon hängt exec-Funktionalität ab?

[David]

Ich stehe vor dem sicher bekannten Problem, dass ich über CGI ein (vor allem auf einem geteilten Server) zeitaufwändiges Skript anstoßen und mit diesem unabhängig vom Apache-Timeout eni später abrufbares Ergebnis erzeugen will.

Ich habe dieses Ansinnen auf unserem internen Testserver (Win32/Apache 2.0/Perl 5.00402) erfolgreich mit folgendem Code realisiert:

script 1.pl
---schnipp---

...

...

$parameter = /* irgendwelche Kommandozeilenparameter*/);

close(STDIN);
close(STDOUT);
close(STDERR);
exec ("script2.pl $parameter");

#Ende Script 1.pl
---schnapp---

Die o.g. Form von exec habe ich gewählt, da exec(param1, param2, ...) nicht ging und der KOmmandozeilenparameter auch erst zur Laufzeit erzeugt wird, was so irgendwie einfacher ging. Script2.pl zieht sich die einzelnen Parameter dann aus $ARGV[0] und erzeugt ein Ergebnis (konkret eine Datei).

Wie gesagt, hier auf unserer Umgebung klappt das so genau nach Plan. Auf dem Server des Providers (Linux/Apache 1.3/Perl 5.00503) klappt das jedoch nicht, warum, weiß der Provider auch nicht; wissentlich habe er keine diesbezüglichen Restriktionen eingerichtet. Perl spuckt dort auch außer ein paar Warnungen (die aber nichts damit zu tun haben) nichts verdächtiges auf dem Fehlerkanal aus.

Antworten und alternative, erprobte Lösungswege gerne (auch) an selfhtmlforum-bei-davidbln(punkt,-)de, ich schaue aber auch hier die nächste Zeit immer mal rein.

Danke im Voraus!

[MatzeA]

Servus,

1. schick doch mal die Warning mit.
2. Was tut das 2. Script, welches Du aufrufst.
   Poste es doch mal
   Wird es überhaubt aufgerufen?

Gruss Matze

[David]

Hallo Matze,

1. schick doch mal die Warning mit.

Wäre etwas umfangreich, es sind aber nur Warnungen zur Redeklaration von my-Variablen (""my" variable $... masks earlier declaration"), die aus einigen Modulen stammen, die mit den konkreten Funktionen definitiv nichts zu tun haben.

2. Was tut das 2. Script, welches Du
   aufrufst.
      Wird es überhaubt aufgerufen?

Was es tun SOLL: Es soll einige Logs auswerten und das Ergebnis in einer durch den Kommandozeilenparameter vorgegebenen Weise in einer Datei mit durch den K. vorgegebenem Namen speichern.
Was es tatsächlich tut: Nichts, ich habe extra eine Testfunktion ganz an den Anfang gesetzt, die sofort eine Spur (in Form einer 1-Byte-Datei) hinterlassen würde. Also bin ich mir ziemlich sicher, dass es nicht aufgerufen wird und an diesem Punkt möchte ich ja auch gern wissen, warum nicht; wie gesagt, in der Intranetumgebung hier klappt es ja mit identischem Code.

Poste es doch mal

Dafür ist es ein paar Zeilen zu lang ;) (mit ein Grund fürs Entkoppeln ;-))

Gruß
David

[MatzeA]

Servus,

mir fällt da inzwischen nur noch eines ein.
Lass Dir per echo ausgeben ob ds Script tatsächlich was tut.
2. Stellt sich mir die Frage, ob Du genügend Rechte hast eine Datei zu erstellen und darin was rein zu schreiben.
3. Wurde die 2. Datei auch entpürechend verändert, dass oben #!/usr/bin/perl ... steht und verweisst es auf das richtige Perl.

4. Hat die 2. Datei ebenfalls die richtigen Rechte gesetzt, um von Deinem Benutzer ausgefürt zu werden?

Gruss Matze

[David]

Lass Dir per echo ausgeben ob ds Script tatsächlich was tut.

Auf dem Remoteserver? Falls Du das meinst, ich lasse das 2. Script ja zum Test eine kurze Datei schreiben. Telnet-Zugang um es remote von der Kommandozeile zu prüfen habe ich allerdings leider nicht.

2. Stellt sich mir die Frage, ob Du genügend Rechte hast eine Datei zu erstellen und darin was rein zu schreiben.

Versteht sich, Script 2 wurde ja vorher (Leicht verändert) direkt vom Browser aus gestartet, und da klappts ja.

3. Wurde die 2. Datei auch entpürechend verändert, dass oben #!/usr/bin/perl ... steht und verweisst es auf das richtige Perl.
4. Hat die 2. Datei ebenfalls die richtigen Rechte gesetzt, um von Deinem Benutzer ausgefürt zu werden?

Versteht sich auch, habe ich ansonsten aber auch geprüft, indem ich Script 2 direkt vom Browser aus angestoßen habe.

Gruß
David

[MatzeA]

Servus,

2. Stellt sich mir die Frage, ob Du genügend Rechte hast eine Datei zu erstellen und darin was rein zu schreiben.
   Versteht sich, Script 2 wurde ja vorher (Leicht verändert) direkt vom Browser aus gestartet, und da klappts ja.

Das ist jetzt ne gute Frage..... Kannst Du mir mal die ACL geben sprich die 777 oder was auch immer die Datei für rechte gesetzt hat?

3. Wurde die 2. Datei auch entpürechend verändert, dass oben #!/usr/bin/perl ... steht und verweisst es auf das richtige Perl.
4. Hat die 2. Datei ebenfalls die richtigen Rechte gesetzt, um von Deinem Benutzer ausgefürt zu werden?
   Versteht sich auch, habe ich ansonsten aber auch geprüft, indem ich Script 2 direkt vom Browser aus angestoßen habe.

Das leuchtet nur teilweise ein. Der Header muss schon stimmen. Wenn Du mit dem Browser ein CGI Script anstösst, handelt der Webserver selbst die Ausführung des Scriptes über den gewählten Interpreter.
Beim Ausführen des Scriptes über die Comandozeile, was letzenendes der exec befehl macht, muss die erste angabe mit #!usr/bin/perl etc. auf jeden Fall stimmen.

Auch muss der Internetbenutzert nicht =  dem Ausführenden Benutzer sein. Dabei bin ich mir jedoch nicht 100% sicher.

Gruss Matze

Gruß
David

[fastix®]

Moin!

[1] Starte einfach das Skript durch Aufruf vom Webbrowser aus.
[2] Kopiere alle betreffenden Zeilen aus dem Error- Log in eine neue Datei.
[3] Stelle dies auf einem Webserver zur Verfügung.

Irgendwas findet sich da immer.

Das die "Spur" für den Ablauf des Skriptes nicht gelegt wird läßt läßt drei Dinge vermuten:

a) das Skript wird gar nicht ausgeführt.
Oder:
b) die Pfade zu den Dateien, die du lesen schreiben willst stimmen nicht. Du brauchst da komplette Pfade ausgehend vom Root des
->Dateisystems<-
Oder,
c) wie Matze schon schrieb: was ist mit den Datei - und Verzeichnisrechten?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[David]

Hallo!

[1] Starte einfach das Skript durch Aufruf vom Webbrowser aus.

Da läuft es, nur eben viel zu lang um sicher vor dem Timeout geschützt zu sein, daher ja der andere Versuch.

[2] Kopiere alle betreffenden Zeilen aus dem Error- Log in eine neue Datei.
[3] Stelle dies auf einem Webserver zur Verfügung.
Irgendwas findet sich da immer.

Wie gesagt: Es sind ausschließlich Meldungen des ersten Skriptes, die sich ausschließlich auf "my-Redeklarationen" beziehen, und die entstehen beim Einlesen der Module, die ich auch mit allen anderen Skripts verwende.

a) das Skript wird gar nicht ausgeführt.

Ja, ich bin sicher, dass das so ist. Nur WARUM?! Ich habe zwei Vermutungen, zu denen ich aber keine Lösung habe: a) etwas am ge-exec-ten Kommando ist falsch, b) Es gibt eine Option in Perl oder Apache, die der Provider mal gesetzt hat und die der Supportmitarbeiter zu finden nicht in der Lage ist (obwohl der ansonsten immer recht pfiffig ist). In dieser Richtung wären mir sachdienliche Hinweise am liebsten...

b) die Pfade zu den Dateien, die du lesen schreiben willst stimmen nicht. Du brauchst da komplette Pfade ausgehend vom Root des
->Dateisystems<-

Versteht sich, DOCUMENT_ROOT frage ich aber eh aus dem ENV ab, das kann es also nicht sein.

c) wie Matze schon schrieb: was ist mit den Datei - und Verzeichnisrechten?

Laufen mit allen Scripts, sprich sind ausreichend vorhanden.

Gruß
David

[Andres Freund]

Hi David,

b) Es gibt eine Option in Perl oder Apache, die der Provider mal gesetzt hat und die der Supportmitarbeiter zu finden nicht in der Lage ist (obwohl der ansonsten immer recht pfiffig ist). In dieser Richtung wären mir sachdienliche Hinweise am liebsten...
Dann informier dich mal über den tainted Modus. Es kann sein, dass es dadran liegt, dass du Probleme hast.

Grüße Andres Freund

[David]

Dann informier dich mal über den tainted Modus. Es kann sein, dass es dadran liegt, dass du Probleme hast.

Hallo Andreas, hast Du einen Tipp wo genau ich mich dazu am besten informiere? Dank im Voraus!

David