PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : php files werden im source ausgeliefert (manchmal)



relli
25.01.07, 16:46
Hi,

Habe folgendes kritisches Problem:

SuSE 10.2 als Basis

Diverse Webseiten ( ca. 400 Domains)
Sporadisch scheint php keine Files mehr zu parsen.
Eigentlich kenne ich das Problem nur in Verbindung mit php 4.3x.
Irgendwie finde ich dazu keinen anhaltspunkt mehr.
Die Scripte werden überhaupt nicht geparst - es ist also kein mime-problem wo nur der geparste content zum download angeboten wird.

Any Ideas ?

Grüße
Micha

marce
25.01.07, 17:17
any logentries?
any configs?
any infos?

j(ay)son
25.01.07, 18:31
Hast du in deiner httpd.conf das php modul geladen und
AddType application/x-httpd-php .php hinzugefügt?

Ich kann mir nicht vorstellen, dass dies Problem etwas mit PHP zu tun hat sonder eher mit Apache.

Ansonsten du mal das was marce vorgeschlagen hat.

MfG Jay

derRichard
25.01.07, 21:03
Diverse Webseiten ( ca. 400 Domains)
hallo!

ist die kiste überhaupt für sowas ausgelegt?
weil ganz trivial ist das nicht mehr bei solchen mengen an domains.
da bekommst dann probleme mit den filedescriptorgrenzen von linux.

hth,
//richard

relli
26.01.07, 10:17
Nein - nada - nix.
Die Maschine lief vorher mit Suse 7.3 und wurde aufgrund von akuten patchmangel auf 10.2 hochgezogen.
Alles was homedir war wurde übernommen. Der rest komplett neu.

relli
26.01.07, 10:20
Hast du in deiner httpd.conf das php modul geladen und
AddType application/x-httpd-php .php hinzugefügt?

Ich kann mir nicht vorstellen, dass dies Problem etwas mit PHP zu tun hat sonder eher mit Apache.


Im ersten Posting steht hierzu bereits die Antwort.
Ja - der Type passt , und es werden ja auch seiten geparst.
Es bleibt nachvollziehbar und sieht verdammt nach dem gleichem Problem aus wie bei php 4.3.4. Sobald ein vhost php_engine off hat und der gleiche preforked prozess danach einen mit engine on bekommt gibts quellcode statt geparstes php.

Grüße
Micha

relli
26.01.07, 10:21
Ja ist Sie - hab leider nicht dazu geschrieben das die Maschine schon vorher die Last hatte. Es wurde nur das System ersetzt.

Gruß
Michael

derRichard
26.01.07, 13:19
hallo!

eigentlich hatte ich die software-konfiguration gemeint mit der auslegung...

bei so vielen domains würde ich php sowieso als cgi laufen lassen.
dann ist jedes php-skript ein eigener prozess und linux kann viel besser skalieren.

dir ist die problematik mit den filedescriptorgrenzen schon bekannt, oder?
siehe:
http://httpd.apache.org/docs/2.2/vhosts/fd-limits.html

//richard

relli
26.01.07, 16:35
Ja, ist sie und das sollte nicht das Problem sein:
cat /proc/sys/fs/file-max
102423

Zu den normalen Lastzeiten komme ich nicht über 40k.

php als cgi wäre nett - aber die maschine hat dafür zu wenig speicher.

Naja, wenn alle nicht hilft ziehe ich die mit phpengine off auf eine alte kiste um.

Danke für die Antwort trotzdem.

Grüße
Michael Reck

derRichard
26.01.07, 16:42
Ja, ist sie und das sollte nicht das Problem sein:
cat /proc/sys/fs/file-max
102423

Zu den normalen Lastzeiten komme ich nicht über 40k.

php als cgi wäre nett - aber die maschine hat dafür zu wenig speicher.

Naja, wenn alle nicht hilft ziehe ich die mit phpengine off auf eine alte kiste um.

Danke für die Antwort trotzdem.

Grüße
Michael Reck
hallo!

naja, file-max gibt an wie viele in summe maximal geöffnet sein dürfen.
aber es gibt noch ein limit pro prozess. und das ist per default auf 1024 gestellt.
(siehe konstante NR_OPEN in include/linux/limits.h)
das ist das problem. mit file-max selber hat man nie probleme.

//richard

relli
29.01.07, 09:15
Ich mach jetzt nen Bugreport bei SuSE auf. Es ist kein Problem mit den Filehandlern. Es scheint irgendwie wieder der 4.3.x Bug zu sein.
Ich habe den Webserver auf einen child begrenzt und eine Seite mit php_engine_off geladen - unmittelbar danach eine mit eingeschaltenem php - schwupps - schon sehe ich quellcode. Als workaround haben halt jetzt alle php bis das (sauber) behoben ist.

Grüße + Dank an alle

Micha