FastCGI / Error 500 --> mod_fcgid

[MoritzDorn]

Ich seh, dass es ein 500 Error ist, weil ich ihn ja ständig sehe, ich komm ja nicht mehr in den Admin Bereich, sondern auf die 500 Error Seite

Wie bekomm ich das wieder zum laufen?

[monotek]

Du wirst doch sicher ein Backup der Config Dateien haben?

Ansonsten vielleicht am Besten nen neuen Thread eröffnen, damit dieser hier weiter zur Diskussion über mod_fcgid verwendet werden kann.

[ephigenie]

um nochmal auf mod_fcgid zurückzukommen ...
Ich habe hier auch fcgid am laufen - allerdings hats die 500er auch nicht vollständig im Griff - das Problem lies sich nur mit mehr FCGI_CHILDREN lösen ...

Also eher so eine Art php <-> fastcgi Sache.

[monotek]

Ich habe inzwischen auch gelesen, dass mod_fcgid etwas performanter als mod_fastcgi sein soll.

Wenns die 500 Errors also wenigstens etwas eindämmt und dazu noch performanter wäre, würde ich einen Austausch der Module vorschlagen. mod_fastcgi wird ja angeblich auch nicht mehr weiter entwickelt.

Natürlich müsste das vorher mal genau evaluiert werden. Eventuell gibts ja auch noch andere Lösungsansätze?

Angeblich liegts auch oft an zu wenig Arbeitsspeicher?

http://support.genotec.ch/index.php?_m=k...nav=0,3,44

Kann jemand bestätigen, dass die Errors nachlassen, wenn man das PHP Memory Limit erhöt?

[ephigenie]

Nein - das dürfte hauptsächlich applikationsspezifisch sein.

Das Problem ist - dass in manchen Fällen php einfach "abschmiert" (z.B. manchmal bei "memory exhausted" o.ä. ) der Server hat dann keine Möglichkeit mehr festzustellen was passiert ist mit dem php - prozess und da die fastcgi Verbindung abgerissen ist schmeisst er einen 500er.

Es liegt aber in der Natur der Sache, die Php.ini entsprechend den Bedürfnissen anzupassen - Speicher wird ja nur soweit alloziiert wie er auch gebraucht wird.
Überlicherweise sind heutzutage Werte je nach dem zwischen 8-64Mb Mem Limit normal. Bei niedrigpreisigen Angeboten halt eher 8 bei besseren eher 64.
Es versteht sich von selbst, dass anspruchsvolle Anwendungen wie z.B. typo3 etc. eher mehr Ram als weniger brauchen. Damit kommen wir aber zu einem Vor - bzw. auch Nachteil der Fastcgi Sache - man kann eben für jeden Host eigene Werte festlegen - das könnte man natürlich auch mal irgendwie im Panel integrieren, dann lassen sich solche Werte dann z.B. auch im Hostingplan hinterlegen.

Jedoch würde ich sagen - die meisten Fehler basieren einfach auf zu wenigen "Request-Slots" bzw. zu wenigen FCGI_CHILDREN 's .
mod_fcgid hat im übrigen ähnliche Probleme mit dem töten überflüssiger php-prozesse wie mod_fastcgi weil es einfach ein php Problem ist und kein fastcgi Problem.

der Umstieg zwischen mod_fcgid und mod_fastcgi ist recht einfach.

Zu Aussagen zur Performance zwischen den beiden Varianten lasse ich mich nicht so einfach hinreissen - wenns um Fastcgi geht bevorzuge ich im größeren Stil eher lighttpd / nginx.
Deren Fastcgi Implementierungen sind wirklich gut gelungen - und schnell .
Apache hat schon immer einen etwas anders gearteten multi-purpose Ansatz gehabt - den solche Spezialisten nicht erfüllen können.

[monotek]

Warum dann nicht gleich lighthttpd verwenden?
Gibts da Nachteile durch irgendwelche Inkompatibilitäten zu Apache?

Mit der Performance hab ich auch schon unterschiedliche Aussagen gefunden. Die Mehrheit sichert jedoch mod_fcgid die bessere Performance zu.

Das mit der eingestellten Entwicklung von mod_fastcgi war scheinbar nur ein Gerücht. Die letze Version 2.4.6 ist vom 11.11.07.

[sharky2k]

mod_fastcgi bekommt afair keine security updates durch debian, im gegensatz zu mod_fcgid, u.a. daher die vorliebe einiger leute zu fcgid.

habe mit fcgid in verbindung mit ispcp allerdings auch so meine problemchen.
die ispcp seiten selbst laufen wunderbar mit fcgid (wohlgemerkt mit eigener php.ini, habe im gegensatz zu dr4g0nl0rd lediglich anstelle von sethandler fcgid-script ein addhandler fcgid-script .php genutzt und die fcgid.conf vom apachen so gelassen wie sie war)
erstelle ich jedoch eine neue domain und binde fcgid analog zur 00_master.conf ein, bekomm ich beim aufruf eines php skripts auf diesen domains einen 403. suexec.log und error.log vom apachen sagen dazu erstmal garnichts und im domain eigenen error log wird auch nüscht eingetragen.
kommentiere ich die wrapper zeile und die zeile mit AddHandler fcgid-script .php aus, wird mir die .php allerdings zum download angeboten. Verstehe also momentan nicht wirklich was da schief läuft (wie auch, bekomme ja nichts in den logs....)

[Tolga]

Hi @ all,

also ich habe nun seit ca. 2 Wochen schwerwiegende Probleme mit ca. den gleichen Ansätzen.

System: etch und ISPCP 2b
etch und ISPCP 3

Hardware: AMD 3200+ 2 GB RAM auf beiden maschinen.

auf der ersten Maschine (RC2b) war bei 177 Domains feierabend. Da ging nichts mehr kein apache noch nicht mal mehr ne 500.er Meldung.

Erst als ich hin gegangen bin und mit "ulimit -n 3072" den limit erhöht habe ging zumindest mal HTML wieder... von php keine spur.

Weitergegangen und in der ispcp.conf unter /etc/apache2/sites-available/ispcp.conf
Domains einfachmal auskommentiert....

Und siehe da php läuft wieder...

Habe hier im forum gepostet...
Dann hat es geheissen ich soll doch einfach die neue RC3 aufsetzten..
Habe ich getan...
Da war dann bei 253 Domains feierabend...

also ulimit wieder erhöht und HTML geht wieder ...
ERRORLOG in der ispcp.conf für jede Domain auskommentiert...
leerzeilen rausgeschmissen und es geht voran.
Der server läuft wieder aber wann der nächste tote punkt kommt kann ich denke ich daruf warten..

Code:

[Sat Nov 24 14:19:53 2007] [error] [client 192.168.1.40] FastCGI: incomplete headers (0 bytes) received from server "/var/www/fcgi/master/php5-fcgi-starter"
[Sat Nov 24 14:20:21 2007] [error] [client 192.168.1.40] (2)No such file or directory: FastCGI: failed to connect to server "/var/www/fcgi/master/php5-fcgi-starter": socket file descriptor (1027) is larger than FD_SETSIZE (1024), you probably need to rebuild Apache with a larger FD_SETSIZE

Jetzt sagt mir das der server...
Aber es kann ja nicht sein das ich den Apache neu kompolieren muss...

das hängt irgendwie mit dem ulimit zusammen...
jedoch geht der Server immerwieder her und verändert auch den ulimit wieder auf 1024 .. ich finde einfach den punkt nicht wo ich das ganze ordentlich einstellen kann...

für hilfe wäre ich sehr dankbar..

Grüße
Tolga

[monotek]

Probier doch mal, ob Dir der mod_fcgid Ansatz was bringt.

[ephigenie]

du solltest evt. das ulimit usw. in der /etc/init.d/apache2 hinterlegen.

Das mit den Filedescriptoren ist so ein typisches Apache Problem


Add the following lines to /etc/sysctl.conf:

fs.file-max = 65536

Run the following shell command:
/sbin/sysctl -w fs.file-max=65536

Note that the value fs.file-max can be equal up to 220=1048576).

Add the following line to beginning of /etc/init.d/apache2 and /usr/sbin/apache2ctl:

ulimit -n `cat /proc/sys/fs/file-max`

Change __FD_SETSIZE value in /usr/include/bits/typesizes.h and /usr/include/nptl/bits/typesizes.h files. It should be like:

#define __FD_SETSIZE 65536

Download and rebuild packages:
# apt-get install apt-src
# apt-src --build install openssl
# dpkg -i libssl*.deb openssl*.deb
# apt-src --build install apache2
# dpkg -i libapr*.deb apache2_*.deb apache2-common*.deb apache2-mpm-worker*.deb apache2-utils*.deb
# /etc/init.d/apache2 restart
# apt-src --build install libc-client2002edebian
# dpkg -i libc-client-dev_2002edebian1-*.deb libc-client2002edebian*.deb mlock*.deb
# apt-src --build install php4
# dpkg -i `ls *deb|grep php4|grep -v apache-mod`

How to prevent your rebuilt packages from overwriting during the system upgrade you can find in the article:

http://www.debian.org/doc/manuals/apt-ho...html#s-pin