Probleme mit selbstkompiliertem PHP 5.2.3 als Modul

Hallo,

ich habe heute mein lokales PHP 5.2.3 als Modul für den Apache 2.2.3=20
unter Debian Testing neu compiliert. Seitdem ergibt sich folgendes Proble=
m:

- Das Modul wird vom Apache offenbar richtig geladen, denn das=20
Firefox-Plugin Live HTTP Headers zeigt mir das Modul mit dem Apachen an.

- Rufe ich eine PHP-Datei im Apachen auf, bleibt die Seite jedoch leer.=20
Auch der Quellcode der Seite ist vollkommen leer.

- Rufe ich ein Script auf, das den Code

phpinfo();
?>

enthält, wird mir selbiges zum Download angeboten. Das passiert nur mit=
=20
diesem Script. Rufe ich andere Scripte auf, bleibt, wie oben=20
beschrieben, die Seite leer. Alle Scripte haben die richtige Extension.

Der relevante Auszug aus der apache2.conf:

DirectoryIndex index.html index.htm index.cgi index.pl index.php
AddType application/x-httpd-php .php
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf

In /mods-enabled/ stehen zwei Symlinks auf php5.conf und php5.load in=20
/mods-available/.

Das errorlog vom Apachen zeigt keine Besonderheiten. Das accesslog loggt =

diese Zugriffe auf PHP-Dateien gar nicht.

Das ist wahrlich nicht meine erste PHP-Installation, und so einen=20
Totalausfall hab ich noch nie erlebt. Ich weiß nicht mehr weiter. Hat=20
jemand vielleicht eine Idee?

Grüße,

Alex

Re: Probleme mit selbstkompiliertem PHP 5.2.3 als Modul

Alexander Schestag schrieb:
> Hallo,
>
> ich habe heute mein lokales PHP 5.2.3 als Modul für den Apache 2.2.3
> unter Debian Testing neu compiliert. Seitdem ergibt sich folgendes Problem:
>
> - Das Modul wird vom Apache offenbar richtig geladen, denn das
> Firefox-Plugin Live HTTP Headers zeigt mir das Modul mit dem Apachen an.
>
> - Rufe ich eine PHP-Datei im Apachen auf, bleibt die Seite jedoch leer.
> Auch der Quellcode der Seite ist vollkommen leer.

Schaut so aus als ob PHP waerend der Ausfuehrung stirbt. Kannst ja mal
mit strace mitschauen was passiert.... und dann mal ein minimal PHP
bauen um zu schauen obs an einer der Extensions liegt. Solltest du nen
Backtrace machen koennen kannst du hinterher nen Bugreport machen.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Re: Probleme mit selbstkompiliertem PHP 5.2.3 als Modul

Hallo Jörg,

Joerg Behrens wrote:
> Alexander Schestag schrieb:
>> Hallo,
>>
>> ich habe heute mein lokales PHP 5.2.3 als Modul für den Apache 2.2.3=
=20
>> unter Debian Testing neu compiliert. Seitdem ergibt sich folgendes=20
>> Problem:
>>
>> - Das Modul wird vom Apache offenbar richtig geladen, denn das=20
>> Firefox-Plugin Live HTTP Headers zeigt mir das Modul mit dem Apachen a=
n.
>>
>> - Rufe ich eine PHP-Datei im Apachen auf, bleibt die Seite jedoch=20
>> leer. Auch der Quellcode der Seite ist vollkommen leer.

> Schaut so aus als ob PHP waerend der Ausfuehrung stirbt.

Du scheinst Recht zu haben. Ich habe mittlerweile via tail -f=20
/var/log/apache2/error.log herausgefunden, daß da zumindest in einigen =

Fällen was segfaultet. Das hatte ich bisher übersehen, weil die Meldu=
ng=20
nicht immer kommt.

[Mon Jun 18 11:46:32 2007] [notice] child pid 4119 exit signal=20
Segmentation fault (11)

Ich habe diverse Bugreports gefunden, die ähnliches im Zusammenhang mit=
=20
Extensions berichten. strace während des Ladens eines php-Scripts sieht=
=20
so aus:

select(0, NULL, NULL, NULL, {1, 0}) =3D ? ERESTARTNOHAND (To be resta=
rted)
--- SIGCHLD (Child exited) @ 0 (0) ---
select(0, NULL, NULL, NULL, {0, 964000}) =3D ? ERESTARTNOHAND (To be=20
restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
select(0, NULL, NULL, NULL, {0, 956000}) =3D 0 (Timeout)
clone(child_stack=3D0,=20
flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,=20
child_tidptr=3D0xb784f708) =3D 4205
waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}],=20
WNOHANG|WSTOPPED) =3D 4150
gettimeofday({1182160755, 363170}, NULL) =3D 0
write(7, "[Mon Jun 18 11:59:15 2007] [noti"..., 87) =3D 87
waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}],=20
WNOHANG|WSTOPPED) =3D 4183
gettimeofday({1182160755, 363420}, NULL) =3D 0
write(7, "[Mon Jun 18 11:59:15 2007] [noti"..., 87) =3D 87

Das Problem ist offensichtlich: SIGCHLD bzw. SIGSEGV. Könnte die=20
Funktion gettimeofday, die da aufgerufen wird, der Übeltäter sein?=20
Leider dauert bei mir ein Compile auf meiner alten Kiste mitunter eine=20
halbe Stunde und bringt den Rechner auch wärmemäßig an die Grenze d=
er=20
Belastung, so daß es leider nicht praktikabel ist, jetzt schrittweise=20
die Extensions wieder reinzutun und zu schauen, wo das Problem auftritt. =

Hättest du (oder jemand) noch eine andere Idee, wie man die=20
verantwortliche Erweiterung finden könnte? Da das Problem bei jedem=20
Allerweltsscript auftritt, vermute ich was ganz Grundlegendes.

Grüße,

Alex