Servererror 500 bei fopen von PHP-Dateien (Apache2, PHP5-FastCGI)

[roi]

Hallo,

ich betreibe einen Server mit Apache2 / PHP5-FastCGI. Die Installation habe ich nach der Debianhowto.de Anleitung durchgefuehrt. Einziger Unterschied: Nichts selbst kompiliert, ausschliesslich vorhandene und offizielle Pakete verwendet (weil die Anleitung hier nicht allzu aktuell ist).

Das hier habe ich weggelassen...

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN

...da ich der Empfehlung glaubte, dass das Prozessmanagement das schon selbst macht.

Server lief perfekt bis eine Sache eines Kunden aufkam: Per fopen eine PHP-Datei auf dem gleichen https-VHost zu oeffnen. Nach einer Wartezeit war ein Error 500 zu sehen, in den Logfiles wurde von "incomplete headers", "segmentation faults" und mehr geredet (gerne kann ich bei Interesse ein paar entsprechende Auszuege hier posten).

Hier das fopen Testscript:

Code: Select all

<?
    $url = "https://www.domain.tld/index.php";
    if ($fd = @fopen($url,"r"))
        echo "Success";
    else
        echo "Failure";

    fclose($fd);
?>

Witzigerweise lief das Testscript auf einem identisch konfigurierten http-Host perfekt, waehrend es auf dem https-Host nicht lief.

Nun fiel mir nach langem Hin und her auf, dass es kein Problem ist, Dateien auf anderen Webservern bzw VHosts auf der gleichen Maschine zu oeffnen. Nur auf dem gleichen VHost kam es zu Problemen. Die Kroenung: Durch Zufall fiel mir dann auch noch auf, dass nur PHP-Dateien die Probleme verursachen. TXT oder HTML konnte problemlos geoeffnet werden.

Des Raetsels Loesung fuer mich: Diese beiden Zeilen...

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN

doch verwenden, und schwupps - Problem weg!

Ein zuvor ausgefuehrter "ps aux | grep php" ergab auch, dass bisher eben nur ein Childprozess gestartet wurde. Kein Wunder also fuer mich, dass sich der Server dann schwer tat, zwei PHP-Dateien gleichzeitig zu interpretieren.

Nun frage ich mich folgendes:

1) Warum funktioniert dieses vielgelobte Prozessmanagement nicht?
2) Warum funktionierte das Testscript auf dem identisch konfigurierten http-Host?

:roll:

Vielleicht kann mir hier jemand weiterhelfen... Denn obwohl das Problem geloest ist, bleiben fuer mich jetzt an sich noch mehr Fragen zurueck wie vorher. V.a. weil ich nun u.U. vor dem Problem stehe, mir fuer die Anzahl der Childs etwas ueberlegen zu muessen.

Viele Gruesse,
Roi

[Roger Wilco]

...da ich der Empfehlung glaubte, dass das Prozessmanagement das schon selbst macht.

Da lügt die Readme. Ich zitier mal schnell die Stelle Code:

Code: Select all

        /* Pre-fork, if required */
        if (getenv("PHP_FCGI_CHILDREN")) {
                children = atoi(getenv("PHP_FCGI_CHILDREN"));
                if (!children) {
                        fprintf(stderr, "PHP_FCGI_CHILDREN is not validn");
                        return FAILURE;
                }
        }

Oder kurz: Wenn du PHP_FCGI_CHILDREN nicht explizit setzt, wird nichts geforkt. Siehe auch http://bugs.php.net/bug.php?id=37422 und http://bugs.php.net/bug.php?id=27802

[roi]

...da ich der Empfehlung glaubte, dass das Prozessmanagement das schon selbst macht.

Da lügt die Readme. Ich zitier mal schnell die Stelle

<...>

Oder kurz: Wenn du PHP_FCGI_CHILDREN nicht explizit setzt, wird nichts geforkt. Siehe auch http://bugs.php.net/bug.php?id=37422 und http://bugs.php.net/bug.php?id=27802

Na Prost Mahlzeit... Super! Danke fuer die Information, nun wird mir einiges klar...

Versteh ich das nun richtig, dass ich PHP_FCGI_CHILDREN unbedingt setzen muss?

Hast Du mir zufaellig eine Einstellung, die empfohlen wird? Und das wuerd ich sowohl fuer Webseiten, die dediziert auf einem Server laufen sowie Webseiten (teilweise Webseiten, auf denen wenig bis gar nichts los ist und teilweise Webseiten, auf denen viel bis sehr viel los ist), die mit Dutzenden anderen auf einem Shared-Hosting Server laufen, brauchen...

Hab mich damals bei der Umstellung auf Apache2/PHP5 versucht im Netz zu belesen nach passenden Einstellungen fuer PHP_FCGI_CHILDREN, hab aber keine befriedigenden Antworten gefunden.

Viele Gruesse,
Roi

[Roger Wilco]

Versteh ich das nun richtig, dass ich PHP_FCGI_CHILDREN unbedingt setzen muss?

Ja, sonst werden keine FastCGI-Prozesse im Voraus geforked. Siehe auch http://trac.lighttpd.net/trac/wiki/Freq ... httpdspawn

Hast Du mir zufaellig eine Einstellung, die empfohlen wird?

It depends...es kommt einfach darauf an, wie gut die Seite besucht ist und wieviel davon dynamisch generiert wird. Einen pauschal optimalen Wert, der immer gilt, gibt es nicht.

[Joe User]

Ich würde ersteinmal mit folgender Config (lighttpd) anfangen und gegebenenfalls langsam steigern:

Code: Select all

fastcgi.server = (
    ".php" => (
        (
            "bin-path" => "/usr/bin/php-cgi",
            "socket" => "/tmp/fastcgi_php.sock",
            "min-procs" => 4,
            "max-procs" => 4,
            "bin-environment" => (
                "PHP_FCGI_CHILDREN" => "4",
                "PHP_FCGI_MAX_REQUESTS" => "250",
            ),
            "bin-copy-environment" => (
                "PATH",
                "SHELL",
                "USER",
            ),
            "broken-scriptfilename" => "enable",
        ),
    ),
)

[roi]

Hast Du mir zufaellig eine Einstellung, die empfohlen wird?

It depends...es kommt einfach darauf an, wie gut die Seite besucht ist und wieviel davon dynamisch generiert wird. Einen pauschal optimalen Wert, der immer gilt, gibt es nicht.

Wie sind denn Deine Erfahrungswerte?

Ich habe zwei verschiedene Szenarien:

1) Shared Webhosting Server mit einer dreistelligen Anzahl von VHosts
2) Dedizierter Server fuer einen Webauftritt

Auf den Shared-Servern gibt es natuerlich drei Arten von Webseiten. Auf manchen ist gar nichts bis superwenig los, auf manchen ist "normaler" Privatkunden- oder Vereinswebseiten/-foren maessig was los und dann gibt es noch Webseiten, auf denen viel los ist (10-20GB Traffic/Monat mit 90% PHP-Traffic.

Welche Erfahrungswerte hast Du denn fuer diese Szenarien?

Momentan ist es so, dass alle Webseiten bis auf die https-Webseite auf dem dedizierten Server, wo ich o.g. Problem hatte, noch ohne einen PHP_FCGI_CHILDREN Wert laufen. Beschwerden gibt es nicht, aber angesichts der gestern gemachten Erfahrung wird diese Konfiguration ja alles andere als gluecklich sein.

Ich würde ersteinmal mit folgender Config (lighttpd) anfangen und gegebenenfalls langsam steigern:

Code: Select all

fastcgi.server = (
    ".php" => (
        (
            "bin-path" => "/usr/bin/php-cgi",
            "socket" => "/tmp/fastcgi_php.sock",
            "min-procs" => 4,
            "max-procs" => 4,
            "bin-environment" => (
                "PHP_FCGI_CHILDREN" => "4",
                "PHP_FCGI_MAX_REQUESTS" => "250",
            ),
            "bin-copy-environment" => (
                "PATH",
                "SHELL",
                "USER",
            ),
            "broken-scriptfilename" => "enable",
        ),
    ),
)

Ich uebersetz das mal in Apache2.

In die php-fcgi-starter kommt folgendes:

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=250
export PHP_FCGI_MAX_REQUESTS

und in die fastcgi.conf kommt folgendes:

Code: Select all

FastCgiConfig -minProcesses 4 -maxProcesses 4

Geh ich da richtig in der Annahme, oder bin ich falsch gewickelt und hab was vergessen?

Joe, auf welche Bedinungen beziehen sich Deine Werte? Webseiten mit wenig Traffic, weil Du schreibst, dass man damit mal beginnen sollte?

Mein Problem ist v.a. die Shared-Webhosting Umgebung. Will einerseits nicht uebertreiben und den Server so dann wahrscheinlich in die Knie zwingen, wenn da auf einmal 4*x (x = Anzahl VHosts) php-cgi Prozesse rumduempeln, andererseits will ich auch nicht, dass es zu Problemen auf den Webseiten kommt.

Vielen Dank fuer Eure Hilfe,
Roi

[Joe User]

Mein Vorschlag bezieht sich auf einen unausgelasteten Webserver (P4 2,4GHz/512MB RAM) mit drei phpBB2 in RF-Grösse, einem gutbesuchtem CMS und elf "normalen" PHP-basierenden Websites (Insgesamt etwa 350GB Traffic im Monat). "Unausgelastet" bedeutet hierbei, dass dort mindestens das Doppelte der bisherigen Webanwendungen problemlos laufen könnten...

[roi]

Ah alles klar. Ich denke, dass ich es mit diesen Werten auch probieren werde. Sollten sich Probleme ergeben, werde ich hier dann auf jeden Fall wieder auftauchen.

Danke fuer die Hilfe!

[cirox]

Hallo,

schön dass mal wieder drüber gesprochen wird, ich habe auch schon angefangen gehabt PHP das Prozessmanagement zu überlassen.

Ich habe natürlich genau dasselbe Problem und werde die hier empfohlenden Werte benutzen für shared Hosting Umgebungen, wo erstmal gar nicht klar ist wieviel Traffic oder etc. die Seiten machen werden also:

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=250
export PHP_FCGI_MAX_REQUESTS

fastcgi.conf:

Code: Select all

FastCgiConfig -minProcesses 4 -maxProcesses 4

Bloss warum "maxProcesses" auf 4?

Ausserdem habe ich es so verstanden, jedenfalls nach Howto, dass man öfters dies machen sollte:

Zitat:
http://archiv.debianhowto.de/de/apache2 ... sarge.html

"Einen guten Startwert hat man gefunden, wenn "ps aux | grep php-fcgi | grep VHOST_USER | wc -l" einen Wert liefert, der in etwa so groß ist, wie der Wert, den man mit PHP_FCGI_CHILDREN eingestellt hat (+-3). Am Anfang ist dies allerdings fast immer der Fall, man sollte deshalb das Ganze mehrmals wiederholen, nach einer Stunde, nach einem Tag, nach einer Woche, um 100% sicher zu gehen. Es ist zu beachten, dass dies für jeden vHost/User extra eingestellt werden muss."

Bloss wie dann die "maxProcesses" einstellen, wenn man z. Bsp. die "PHP_FCGI_CHILDREN" auf 8 erhöhen muss. Auch auf "8" für "maxProcesses" ?

gruß cirox

[roi]

fastcgi.conf:

Code: Select all

FastCgiConfig -minProcesses 4 -maxProcesses 4

Bloss warum "maxProcesses" auf 4?

Die beiden Settings hab ich doch nicht genommen sondern gar nicht angegeben, dh er nimmt die Standardsettings 5 und 50. Haette noch was anderes aendern muessen, denn 4 und 4 kann man nicht nehmen, es kollidiert mit ner anderen Standardeinstellung.

Interessanter Link dazu:
http://www.fastcgi.com/mod_fastcgi/docs ... tCgiConfig

[cirox]

Hallo,

erstmal danke, also ich lese mich ja nun auch schon ne Weile durch und mit jeder Seite ne andere Einstellungen. Echt witzig oder auch nicht ....

also einfach:

Code: Select all

...
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
...

bloss mit dem:

Code: Select all

PHP_FCGI_MAX_REQUESTS=250 

noch dazu und in der fastcgi.conf nichts, also Standard. Komisch, da wären wir doch wieder im Howto angelangt ..... ausser mit dem "PHP_FCGI_MAX_REQUESTS=250 "

gruß cirox

PS: Obwohl man sich das mit den "PHP_FCGI_MAX_REQUESTS=250" ja nun auch sparen kann oder ?

[roi]

So, also ich bin erstmal mit den Settings auf die Schnauze geflogen. Hatte ja, siehe oben, die minProcesses und die maxProcesses nicht auf jeweils 4 gestellt sondern auf den Defaults (5 und 50) gelassen.

Folge: Seitenweise Processlisten mit php5-cgi, Server (Opteronkiste mit 2GB RAM) total am Ende und aus dem letzten Loch pfeifend... Auf dem Server laufen 74 VHosts, auf den meisten ist nichts bis wenig los, auf einer Handvoll ist fuer meine Verhaentnisse viel los (500-2GB Traffic/Monat) und auf einem ist sehr viel los (20-30GB Traffic/Monat).

Apache killen dauerte schon ewig, die php5-cgi Prozesse waren immer noch da und spawnten froehlich weiter. Erst ein "pkill (-9) php5-cgi" brachte den Server wieder zur Ruhe.

Habe nun mal folgende Optionen neu eingebaut in die FastCgiConfig in die Datei fastcgi.conf:

Code: Select all

-minProcesses 4 -maxProcesses 4 -processSlack 4 -maxClassProcesses 4

Nun kotzt sich das globale error.log des Apachen sekuendlich mit mehreren Meldungen aus:

[Thu Nov 09 23:16:41 2006] [warn] FastCGI: can't schedule the start of another (dynamic) server "/var/www/php-fcgi-scripts/www.domain.tld/php-fcgi-starter" process: exceeded dynamicMaxProcs (4)

Dh sauber ist die Config auch nicht unbedingt, immerhin haut's mir nicht wieder die Prozessliste zu und die VHosts produzieren keine 500er Fehler und laufen an sich auch ganz fix.

Aber trotzdem: Sauber ist das wohl nicht, was kann/muss/soll ich daran noch aendern?

Sorry, aber mit dem Thema komm ich mir echt vor wie ein Hobbyelektroniker und schaffe es irgendwie nicht, ne g'scheite Config zu finden.

Danke und Gruss,
Roi

[cirox]

Ja mich interessiert das auch ganz gewaltig sogar ....

Ich halte mich zur Zeit absolut ans Howto, dass heisst, wenn ich mehrProzesse finde als 4 dann erhöhe ich die Zahl der Childs auf 8 usw.

Ich stelle da lieber nichts ein, da so wie so jeder was anderes sagt, und über google nichts wirklich eindeutiges zu finden ist, ausser dass fastcgi seit 2003 nicht mehr weiterentwickelt wird und man das neue nehmen soll. Aber im Moment bin ich genau so wie Du fast mit der gleichen Anzahl von vhost unterwegs usw..

Das Einzige was ich unterlasse ist das über php auszuführen, also die Prozessverwaltung.

gruß cirox

PS: Vielleicht könnte sich ja mal einer melden, der das produktiv im Einsatz hat und mit apache2.0 und php4/5 etc..

[roi]

/EDIT: Hab die Aenderungen von eben direkt wieder rueckgaengig gemacht. Verschiedene Webseiten waren nicht mehr erreichbar. Lieber momentan jeden Tag den Apachen neu starten und die Prozesse aufraemen wie ne nicht funktionierende Config. Der Server lief nach aussen ja unveraendert (dh er reagierte normal) und das bei einem Apache, der ungefaehr ne Woche nicht neu gestartet wurde.

Unsofern waere ich noch viel mehr scharf auf Hilfe von Euch!

Danke!

[roi]

Ich halte mich zur Zeit absolut ans Howto, dass heisst, wenn ich mehrProzesse finde als 4 dann erhöhe ich die Zahl der Childs auf 8 usw.

Mal abgesehen davon, dass das ja mal Turnschuhadministration ist und ich an sich darauf keinerlei Lust habe, wenns irgendwie anders machbar waere:

Du redest hier vom Setting PHP_FCGI_CHILDREN, oder? Was hast Du denn in der fastcgi.conf stehen?

Ich stelle da lieber nichts ein, da so wie so jeder was anderes sagt, und über google nichts wirklich eindeutiges zu finden ist, ausser dass fastcgi seit 2003 nicht mehr weiterentwickelt wird und man das neue nehmen soll.

Wo nix einstellen?

<outing>

Was fuer nen neues FastCGI? An sich war ich bisher der Meinung, dass eine Serverkonfiguration mit Apache2, FastCGI und PHP5 eine sehr normale und gebraeuchliche und aktuelle Konfiguration ist.

</outing>

Aber im Moment bin ich genau so wie Du fast mit der gleichen Anzahl von vhost unterwegs usw..

Das Einzige was ich unterlasse ist das über php auszuführen, also die Prozessverwaltung.

Wie meinen?

PS: Vielleicht könnte sich ja mal einer melden, der das produktiv im Einsatz hat und mit apache2.0 und php4/5 etc..

Mein Server laeuft an sich produktiv. Umso schlimmer die Probleme... ;-)

[cirox]

Hallo

naja das FastCGI ein Problem mit der Prozessverwaltung hat ist ja bekannt. Obs tasächlich ein grosses ist glaub ich nicht denn der Code ist als solches stabil und wird nicht weiterentwickelt. Es gibt dazu eine Mailingliste .... vielleicht sollte man da einfach mal weiter ansetzen.

Klar ist das bestimmt alles fein zu justieren, wäre natürlich schön wenn einer anderer mal Werte aus dem produktiven Einsatz postet.

Die neue Entwicklung findest du hier:

http://www.sf.net/projects/mod-fcgid/

fastcgi.conf:

Code: Select all

FastCgiWrapper /usr/lib/apache2/suexec2
FastCgiServer /var/www/php-fcgi-scripts/web0/php-fcgi-starter -user web0 -group web0

AddHandler php-fastcgi .php
AddHandler php4-fastcgi .php4
 
<Location /php/php-fcgi-starter>
        SetHandler fastcgi-script
        Options +ExecCGI
</Location>
<Location /php/php4-fcgi-starter>
        SetHandler fastcgi-script
        Options +ExecCGI
</Location>
 
Action php-fastcgi /php/php-fcgi-starter
Action php4-fastcgi /php/php4-fcgi-starter
 
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php4

und die jeweiligen starter für php4 und php5, ich poste mal nur einen, da die sich eh nur im Pfad unterscheiden:

Code: Select all

#!/bin/sh
PHPRC="/etc/apache2/confixx/web0/php5"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /home/admin/php/c/php-5.1.6/bin/php-fcgi

ich habe in der Prozessliste natürlich auch so ein paar webs, wo schon 16 Prozesse stehen ......

Mit der Prozessverwaltung meine ich man kann die beiden Zeilen:

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN

auch ganz weglassen, aber dann übernimmt PHP ganz die Verwaltung, aber laut anderen ist das buggy ....

gruß cirox

[roi]

Servus nochmal!

naja das FastCGI ein Problem mit der Prozessverwaltung hat ist ja bekannt. Obs tasächlich ein grosses ist glaub ich nicht denn der Code ist als solches stabil und wird nicht weiterentwickelt. Es gibt dazu eine Mailingliste .... vielleicht sollte man da einfach mal weiter ansetzen.

Klar ist das bestimmt alles fein zu justieren, wäre natürlich schön wenn einer anderer mal Werte aus dem produktiven Einsatz postet.

Waere auf jeden Fall ein Anhaltspunkt. Joe hat ja schon seine Settings gepostet, aber die sind fuer mich wohl unbrauchbar. Oder ich hab was falsch uebernommen oder nur teilweise.

Die neue Entwicklung findest du hier:

http://www.sf.net/projects/mod-fcgid/

Ah ja. Stimmt, ich hab schon oefeters mod_fcgid gesehen, aber mich nie reingelesen. Es gibt sogar ein Debianpaket, wo andauernd Aenderungen gemacht werden.

Warum verwenden dann viele das mod_fastcgi? Ohne jetzt im Forum und bei Google zu suchen (das mach ich morgen, heute ist's mir zu spaet ;-) ): Ist das eher zu empfehlen und falls ja, gibts ein Howto?

fastcgi.conf:

Code: Select all

...

und die jeweiligen starter für php4 und php5, ich poste mal nur einen, da die sich eh nur im Pfad unterscheiden:

Code: Select all

...

Du stellst ja gar nix ein. Interessant. Meine komplette FastCgiConfig sieht so aus:

Code: Select all

FastCgiConfig -autoUpdate -idle-timeout 300 -pass-header Authorization -pass-header HTTP_AUTHORIZATION

Mit der Prozessverwaltung meine ich man kann die beiden Zeilen:

Code: Select all

PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN

auch ganz weglassen, aber dann übernimmt PHP ganz die Verwaltung, aber laut anderen ist das buggy ....

Siehe oben, das geht ja komplett in die Hose. So hab ich es ja mal probiert bis ich auf die fiesen Probleme gestossen bin.