# APACHE: Segmentation fault (11)

## KaterGonzo

Hallo liebe Community,

ich habe das Gefühl, mein Webserver steht unter Beschuss. Ich habe in den letzten Wochen immer wieder mal sporadische Ausfälle. Teilweise ist der Webserver nicht mehr anpingbar, das Web läuft nur ganz langsam oder der Apache hat sich zerschossen. Iptables ist aktiv und nur die Ports 20-22, 80 sind von außen erreichbar.

Gestern war es dann wieder soweit: ich musste den Server kalt neustarten. Danach bin ich die Logs durchgegangen und von 13-15 Uhr tausende solcher Einträge im apache-error-log gefunden:

 *Quote:*   

> [Sat Apr 25 15:21:58 2009] [notice] child pid 29294 exit signal Segmentation fault (11)
> 
> [Sat Apr 25 15:21:58 2009] [notice] child pid 29295 exit signal Segmentation fault (11)
> 
> [Sat Apr 25 15:21:59 2009] [notice] child pid 29296 exit signal Segmentation fault (11)
> ...

 

Ist das wirklich ein Hardware-Fehler (kann den Server nicht ohne weiteres offline nehmen)? Auffällig sind die 20-30 Segmentation Faults pro Sekunde!

Ein paar Infos:

Apache/2.2.10 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8k PHP/5.2.9-pl2-gentoo

Kernel 2.6.27-gentoo-r8

 *Quote:*   

> # iptables -vL
> 
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> 
>  pkts bytes target     prot opt in     out     source               destination
> ...

 

----------

## Mr. Anderson

Ich würde erstmal auf ein kaputtes Modul tippen. Hatte mal ein ganz ähnliches Problem, nur mit geringerer Frequenz. Ursache war eine kaputte php-Installation.

----------

## KaterGonzo

Kann man sowas eingrenzen? Oder Pi mal Daumen alles Module und entsprechende Pakete neu komplilieren?

----------

## Mr. Anderson

Möglicherweise ist nur ein Link zu einer shared library kaputt. Das sollte sich offenbaren mit revdep-rebuild -p. Schon probiert?

----------

## KaterGonzo

Ich aktualisiere 1x im Monat das ganze System mittels 

emerge -uND world

etc-update

revdep-rebuild

daran kann es nicht liegen. Habe jetzt einfach mal apache, php neu kompiliert. Mal schauen, woran es liegt.

ansonsten werde ich mal memtest laufen lassen müssen...

----------

## KaterGonzo

Also, nachdem ich vor einigen Wochen apache, php & Co neu kompiliert hatte, lief das System stabil. Dann vor einigen Tagen wieder die oben erwähnten Segmentation Fault Meldungen, aber der Server bzw. das Web lief weiter. Nach einem Neustart des Apachen waren die Segmentation Faults dann wieder weg.

Vorgestern aber wieder der SuperGau: der HTTP-Service war nicht erreichbar, per SSH konnte ich mich auch nicht connecten, Anpingen funktionierte komischerweise. Nach einem Hard-Reset sind die Services wieder problemlos erreichbar und laufen jetzt seit zwei, drei Tagen wieder. 

Natürlich habe ich sämtliche Logs durchgeforstet. Das einzige auffällige waren wieder die Hunderte bzw. Tausende Segmentation Fault Einträge im Apache Error Log. Mittlerweile habe ich auch Memtest laufen lassen, speichertechnisch gesehen ist alles OK!

Wie kann man so ein Phänomen debuggen? Das dumme ist, dass ich auch gar nicht mehr per SSH auf die Kiste komme, also scheint der apache das gesamte System lahm zu legen. Mit der Zeit wird es einfach nervig... weis jemand Rat?

----------

## musv

Naja, dass das System kaum noch ansprechbar ist, sollte logisch sein, weil das Teil ja nur noch am Logfileschreiben ist. Die sollten übrigens auch entsprechend groß sein. 

Mach halt einfach mal in Update des gesamten Systems. Übrigens: Bei Production-Server würde ich die monatlichen Systemupdates unterlassen und mich eher nur auf die Sicherheitsupdates (glsa-check) beschränken. Never touch a running system. Das Fehlen neuer Features als Hauptgrund für ständige Updates sollte Dich auf einem Webserver grundsätzlich weniger tangieren.

----------

## KaterGonzo

Nur wegen dem Log schreiben? Kann man das nicht irgendwie beschränken?

Kann es eventuell sein, dass ein PHP-Skript Probleme macht?

Das gesamte System updaten? Das mache ich doch regelmäßig mit emerge -uND world und emerge -uND system. Was meinst Du damit?

Ich hatte ja geschrieben, dass ich folgendermaßen vorgehe:

emerge -uND world

etc-update

revdep-rebuild

----------

## manuels

 *schmidtsmikey wrote:*   

> Kann es eventuell sein, dass ein PHP-Skript Probleme macht?

 Vergleiche hierzu doch mal dein Apache access_log mit dem Log, das die Apache-Abstürze protokolliert.

Müsste dann ja zeitlich korrelliert sein.

----------

## musv

 *schmidtsmikey wrote:*   

> Nur wegen dem Log schreiben? Kann man das nicht irgendwie beschränken?

 

logrotate. Das verhindert aber nur die Größe des Logfiles, nicht aber den Schreibvorgang ansich. 

 *schmidtsmikey wrote:*   

> Kann es eventuell sein, dass ein PHP-Skript Probleme macht?

 

Das Script müsste dann den ganzen Apache ins Verderben ziehen. Weiß nicht, ob das geht. 

 *schmidtsmikey wrote:*   

> Das gesamte System updaten? Das mache ich doch regelmäßig mit emerge -uND world und emerge -uND system.

 

Genau das ist der Fehler. Bei einem Production Server solltest du ein mal eine funktionsfähige stabile Installation tätigen und dann nur noch im Fall notwendiger Upgrades (z.B. PHP4 -> PHP5) ein Systemupdate machen. Stattdessen solltest du Dich auf Sicherheitschecks beschränken (glsa-check). 

In Deinem Fall hab ich Dir ein Update vorgeschlagen, da Deine Installation offensichlich fehlerhaft ist und das eventuell mit etwas Glück durch ein Update beseitigt werden könnte. Sofern das nicht hilft, könnte es auch sinnvoll sein, ein Downgrade auf die letzte funktionierende Konfiguration vorzunehmen. 

Und ja, Apache Access Log mit dem zeitlichen Auftreten des Fehlers abzugleichen ist auch sinnvoll.

----------

## tgurr

Hatte vor einiger Zeit mal ähnliche Probleme, damals hatte ich APACHE2_MPMS="peruser" im Einsatz was wohl sehr anfällig für nicht 100%ig saubere HTTP-Anfragen ist, seitdem ich daraufhin auf prefork umgestellt habe hatte ich keine Probleme mehr mit Segfaults. Ansonsten gibt es noch die Möglichkeit ein Pound vorzuschalten um die unsauberen Anfragen schonmal vorneweg auszufiltern.

----------

## dertobi123

Ich hatte ein ähnliches Problem mal mit einer mittels ZendFramework gebastelten Webapp, irgendwas in der Datumskonvertierung war durcheinander und führte zu *nicht reproduzierbaren* Segfaults .... hat mich ein Weilchen gekostet dies rauszubekommen, debuggen ließ sich das nun wahrlich nicht wirklich gut :/

----------

## STiGMaTa_ch

Signal 11 - besser bekannt als ein segmentation fault - bedeutet, dass ein Programm (Apache? Iptables? Sonstwas?) auf einen Speicherbereich zugreifen wollte welcher nicht zugewiesen wurde. Das kann ein Software Problem sein oder aber auf ein Hardware Problem deuten.

Mein P4 3.4 GHz hat mir am Anfang auch etwas Kopfzerbrechen bereitet da das System relativ unstabil war und immer wieder mit Segmentation Faults und dergleichen abgeraucht ist. Schlussendlich war es eine Kombination von falschen Auto-Erkenn-Einstellungen des BIOS sowie ein Temperaturproblem (Mit WaKü wurden keine Segfaults mehr gesichtet.). Ein anderes mal habe ich auf einem System derart massive Probleme gehabt, weil ein RAM Riegel am sterben war. Die Verwendung von memtest über mehrere Stunden kann da behilflich sein.

```

STigMaTa_ch@Laptop ~ $ eix memtest

* sys-apps/memtest86+

     Available versions:  2.01 ~2.10 {serial}

     Homepage:            http://www.memtest.org/

     Description:         Memory tester based on memtest86

* sys-apps/memtest86

     Available versions:  3.3 ~3.4 {serial}

     Homepage:            http://www.memtest86.com/

     Description:         A stand alone memory test for x86 computers

* sys-apps/memtester

     Available versions:  4.0.7 ~4.0.8

     Homepage:            http://pyropus.ca/software/memtester/

     Description:         userspace utility for testing the memory subsystem for faults

```

Hier noch ein Link welcher sich mit Signal 11 beschäftigt.

Lieber Gruss

STiGMaTa

----------

## manuels

 *STiGMaTa_ch wrote:*   

> Hier noch ein Link welcher sich mit Signal 11 beschäftigt.
> 
> 

 

 *http://www.bitwizard.nl/sig11/ wrote:*   

> 
> 
> QUESTION
> 
> Nothing crashes on NT, Windows 95, 98, Milennium or XP. It must be something Linux specific.
> ...

 Naja, habe das mal ueberflogen und hoffe, dass das Niveau dieser Aussage sich nicht fuer diese Seite verallgemeinern laesst.

----------

## STiGMaTa_ch

 *manuels wrote:*   

>  *STiGMaTa_ch wrote:*   Hier noch ein Link welcher sich mit Signal 11 beschäftigt.
> 
>  
> 
>  *http://www.bitwizard.nl/sig11/ wrote:*   
> ...

 

Ohem versteh ich jetzt nicht? Siehst du da irgend ein Bashing? Es ist nunmal Fakt, dass Linux im Gegensatz zu oben genannten Beriebsystemen die HW teilweise mehr in Anspruch nimmt. Die Filesysteme kennen z.B. keine Fragmentierung (zumindest keine so grosse welche man von Hand defragmentieren müsste), weil halt vorzu "aufgeräumt" wird. Das belastet eine HD z.B. mehr als wenn man die Daten einfach hinpappt wo es grad Platz hat und dann irgendwann einmal von Hand "sortiert". Und während bei Linux das RAM so gut wie möglich versucht wird zu füllen wird bei Windows immer wieder das RAM frei gemacht. Da kann es gut sein, dass du bei Linux Fehler merkst die du unter Win nur ganz selten siehst (z.b. weil irgend eines der "hinteren" RAM Bausteine defekt ist und die Chanche, dass diese bei Linux eher mal gebraucht werden eben grösser ist...)

Lieber Gruss

STiGMaTa

----------

## manuels

Das sind aber alles Sachen, die die Performance steigern und so wiederum die Hardware "schonen" (wobei ich nicht sage, dass Linux schonender zur Hardware ist - da tut sich nix).

Wenn die Festplatte fragmentiert ist, koennte ich auch sagen, dass unter Windows die Festplatte mehr lesen und der Kopf hin- und herspringen muss, was die Hardware mehr "stresst".

Ebenso resulitert aus dem "freimachen" des RAMs unter Windows ein haeufigeres Laden von Festplattendaten in den RAM, was die Hardware wiederum mehr "stresst".

Kann man alles so oder so sehen.

Aber wir werden OT.

----------

## robak

sorry für das schänden der leiche  :Wink: 

ich hab aber zZ das selbe problem. apache schmeißt hin und wieder einen segfault. problem bei mir ist mod_soap von php. ich habe zum testen contaoCMS aufgesetzt und mich gewundert dass apache hin und wieder weg ist. das kurriose: der php error wird NUR in die contao log datei geschrieben, im apache error_log landet nichts ausser die segfault meldung.

eine lösung habe ich bisher nicht gefunden, da SOAP von contao erfolderlich ist.

EDIT: vll hilft das weiter, auch wenn der bug älter ist  http://kb.zend.com/index.php?View=entry&EntryID=436

----------

