„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Fehler habe ich auf einem vServer auch, auf meinen normalen dedicated Servern nicht .. ich vermute, es liegt an PHP, denn weder bei cgi noch bei perl und noch bei html oder tcl Scripten habe ich diese Child-die-Probleme
smashie wrote:Fehler habe ich auf einem vServer auch, auf meinen normalen dedicated Servern nicht .. ich vermute, es liegt an PHP, denn weder bei cgi noch bei perl und noch bei html oder tcl Scripten habe ich diese Child-die-Probleme
OOps 8O ebenfalls nach Reinit 1+1 auf SuSE 9.1, Confixx 3.02 + Apache/2.0.49 / PHP 4.3.4 --> Standard --> exit signal Segmentation fault (11)
Dachte zuerst, daß es ein "Hardware" - Fehler sei, RAM oder ähnliches, scheint aber ein Apache/PHP Problem zu sein ...
RealofTime wrote:Ja Speicher dachte ich auch habe ich tauschen lassen... fehler ist immer noch da.....
Habe ich gerade hinter mir ;) --> ging rasend schnell bei 1+1, ABER:
Fehler ist immer noch da :(
Habe leider erst heute Abend/Nacht Zeit dies genauer nachzusehen - vielleicht findet Ihr ja schon ein paar Ansatzpunkte ;)
Die Direktive steuert, ob httpd Memory-Mapping verwenden darf, wenn er während der Auslieferung den Inhalt einer Datei lesen muss. Wenn die Bearbeitung einer Anfrage es erfordert, auf die Daten in einer Datei zuzugreifen -- zum Beispiel bei der Auslieferung einer mittels mod_include serverseitig analysierten Datei --, dann verwendet der Apache standardmäßig Memory-Mapping für diese Datei, sofern das Betriebssystem es unterstützt.
Memory-Mapping bedeutet zuweilen eine Performanceverbesserung. In einigen Umgebungen ist es jedoch besser, Memory-Mapping zu deaktivieren, um Problemen während des Betriebs vorzubeugen:
[...]
Bei einem per NFS eingebundenen DocumentRoot kann httpd mit einem Segmentierungsfehler (Anm.d.Ã?.: ein sogenannter "segmentation fault") abstürzen, wenn eine Datei gelöscht oder gekürzt wird, während httpd sie im Speicher abbildet.
Bei Serverkonfigurationen, die für dieses Problem anfällig sind, sollten Sie das Memory-Mapping für auszuliefernde Dateien deaktivieren
Die Direktive steuert, ob httpd Memory-Mapping verwenden darf, wenn er während der Auslieferung den Inhalt einer Datei lesen muss. Wenn die Bearbeitung einer Anfrage es erfordert, auf die Daten in einer Datei zuzugreifen -- zum Beispiel bei der Auslieferung einer mittels mod_include serverseitig analysierten Datei --, dann verwendet der Apache standardmäßig Memory-Mapping für diese Datei, sofern das Betriebssystem es unterstützt.
Memory-Mapping bedeutet zuweilen eine Performanceverbesserung. In einigen Umgebungen ist es jedoch besser, Memory-Mapping zu deaktivieren, um Problemen während des Betriebs vorzubeugen:
[...]
Bei einem per NFS eingebundenen DocumentRoot kann httpd mit einem Segmentierungsfehler (Anm.d.Ã?.: ein sogenannter "segmentation fault") abstürzen, wenn eine Datei gelöscht oder gekürzt wird, während httpd sie im Speicher abbildet.
Bei Serverkonfigurationen, die für dieses Problem anfällig sind, sollten Sie das Memory-Mapping für auszuliefernde Dateien deaktivieren
wäre vielleicht ein hinweis, oder ?
JA ein hinweiss vielen Dank das habe ich nicht gefunden ich versuche es direkt mal aus... muss dann 1-2 Stunden mal beobachten...
also die fehlermeldung kann viele ursachen haben - ich hab ma was gegoogelt und gleich dutzende von gleichen fehlern, mit jedoch sehr unterschiedlichen ursachen gefunden - wäre vielleicht besser, die aktionen die direkt zum logeintrag führen mit zu posten - zugegeben, nicht ganz einfach - jedoch enorm hilfreich, um zu wissen aus welcher ecke der fehler kommt ...... :idea:
mc5000 wrote:also die fehlermeldung kann viele ursachen haben - ich hab ma was gegoogelt und gleich dutzende von gleichen fehlern, mit jedoch sehr unterschiedlichen ursachen gefunden - wäre vielleicht besser, die aktionen die direkt zum logeintrag führen mit zu posten - zugegeben, nicht ganz einfach - jedoch enorm hilfreich, um zu wissen aus welcher ecke der fehler kommt ...... :idea:
:? tritt leider sporadisch auf, zumindest bei mir...
Habe jetzt etw. Zeit und habe deshalb versucht einen Fehler zu provozieren - just jetzt tritt er nicht auf ... - werde 'mal weiter sehen ...
MMG-Media wrote:Kompiliere mal dein php und update es auf eine aktuelle version 4.3.7.
Dürfte nicht helfen .. ich benutze apache 1.3.31 mit PHP 4.37 .. ich habe den httpD Prozess mal ge'strace'ed jedoch scheint der segfault wilkürlich *einfach so* zu passieren .. naja ich finde mich damit ab :P
MMG-Media wrote:Kompiliere mal dein php und update es auf eine aktuelle version 4.3.7.
Dürfte nicht helfen .. ich benutze apache 1.3.31 mit PHP 4.37 .. ich habe den httpD Prozess mal ge'strace'ed jedoch scheint der segfault wilkürlich *einfach so* zu passieren .. naja ich finde mich damit ab :P
du nutzt dann wahrscheinlich auch wenn du suse verwendest das suse rpm mit 1.3.31, das erzeugt teilweise den selben fehler.
bei mir hat es geholfen, apache sowohl php von hand zu basteln ohne rpm, seit dem hab ich diese fehler nicht mehr.
MMG-Media wrote:Kompiliere mal dein php und update es auf eine aktuelle version 4.3.7.
Dürfte nicht helfen .. ich benutze apache 1.3.31 mit PHP 4.37 .. ich habe den httpD Prozess mal ge'strace'ed jedoch scheint der segfault wilkürlich *einfach so* zu passieren .. naja ich finde mich damit ab :P
du nutzt dann wahrscheinlich auch wenn du suse verwendest das suse rpm mit 1.3.31, das erzeugt teilweise den selben fehler.
bei mir hat es geholfen, apache sowohl php von hand zu basteln ohne rpm, seit dem hab ich diese fehler nicht mehr.
SuSE? Seit mehr als 4 Jahren debian .. und natürlich back ich sowas wie apache und php von Hand ...
Alles komsich wie ich finde.. ich versuche mal PHP zu backen. Vieleicht hilft es was... Ein Tipp ich habe testweise für die ganzen DOmaisn SSL angestellt. Also direkt definiert das es nicht geladne werden soll (ausser Confixx) das hat die faults um 50% minimiert.
Ich hatte den Fehler auch. Ich hab erst den apache auf 2.0.50 geupdatet und dann php von 4.3.4 auf 4.3.8. Der Server läuft jetzt soweit ganz gut. Bis jetzt hab ich keine php Aussetzer mehr gehabt.