Apache2 spinnt nach Online Update

[Rebel2k]

Guten Morgen

ich glaube ich brauche hier mal etwas HILFE!!!

zuerst mein Server:
Pentium 4 rootserver @ strato
SuSe 9.0
Apache/2.0.48 (Linux/SuSE) PREFORK
PHP Version 4.3.3
MYSQL 4.0.15


Ich habe vor gut 8 Tagen mal n Onlineupdate per yast gemacht!
Erst schien alles wunderbar zu laufen, bis ich dann sah das hauptsächlich Webseiten die auf mod_rewrite zugreifen nicht angezeigt werden (Weiße Seite!). Ein Blick in die apache Logs bringt mich auch nicht wirklich weiter :

[Mon Dec 05 10:32:51 2005] [notice] child pid 15758 exit signal Segmentation fault (11)
[Mon Dec 05 10:42:04 2005] [notice] child pid 16024 exit signal Segmentation fault (11)

Ich hab den Fehler mal gegoogelt und evtl. ist es ein Hardware Fehler oder ein Speicherzugriffs Fehler! Die Hardware will ich mal ausschliessen, weil bisher alles andere einwandfrei läuft! MEine Vermutung ist jetzt das nur das mod_rewrite.so Modul des Apache einen weg hat!

Allerdings finde ich es komsich das das modul ein altes Datum besitzt,also nicht neu auf dem System ist:

:/usr/lib/apache2 # ls -liat
3768403 -rwxr-xr-x    1 root     root        12720 Sep  2 22:12 mod_alias.so
3768404 -rwxr-xr-x    1 root     root        35699 Sep  2 22:12 mod_autoindex.so
3768405 -rwxr-xr-x    1 root     root        31955 Sep  2 22:12 mod_cache.so
3768406 -rwxr-xr-x    1 root     root        51378 Sep  2 22:12 mod_dav_fs.so
3768325 -rwxr-xr-x    1 root     root        17239 Sep  2 22:12 mod_deflate.so
3768326 -rwxr-xr-x    1 root     root        19861 Sep  2 22:12 mod_ext_filter.so
3768327 -rwxr-xr-x    1 root     root        42368 Sep  2 22:12 mod_include.so
3768407 -rwxr-xr-x    1 root     root        23848 Sep  2 22:12 mod_log_config.so
3768408 -rwxr-xr-x    1 root     root        36234 Sep  2 22:12 mod_proxy_ftp.so
3768409 -rwxr-xr-x    1 root     root        24259 Sep  2 22:12 mod_proxy_http.so
3768331 -rwxr-xr-x    1 root     root        65012 Sep  2 22:12 mod_rewrite.so
3768411 -rwxr-xr-x    1 root     root        11400 Sep  2 22:12 mod_usertrack.so
3768689 -rwxr-xr-x    1 root     root      1157123 Feb 16  2005 mod_python.so
3768338 -rwxr-xr-x    1 root     root         9459 May 19  2004 mod_access.so
3768339 -rwxr-xr-x    1 root     root         7951 May 19  2004 mod_actions.so
[...]

recht neu sind nur folgende files von apache2 die ich finden konnte:

:/usr/lib/apache2-prefork # ls -liat
3866698 -rwxr-xr-x    1 root     root      2782197 Nov 17 21:12 libphp4.so
3866678 -rwxr-xr-x    1 root     root       201491 Sep  2 22:12 mod_ssl.so
3866628 lrwxrwxrwx    1 root     root           24 Nov 29  2004 mod_access.so -> ../apache2/mod_access.so
3866629 lrwxrwxrwx    1 root     root           25 Nov 29  2004 mod_actions.so -> ../apache2/mod_actions.so
3866630 lrwxrwxrwx    1 root     root           23 Nov 29  2004 mod_alias.so -> ../apache2/mod_alias.so
3866631 lrwxrwxrwx    1 root     root           22 Nov 29  2004 mod_asis.so -> ../apache2/mod_asis.so
[...]

Habt ihr evtl. eine Idee wie ich das Problem wieder aus der Welt bekomme?
Ich trau mich alleine aber auch nicht den apache samt mysql und php mal upzudaten

 

[bishbind]

Hallo,

ich habe seit dem Update das gleiche Problem. Meine Serverkonfiguration ist mit meiner identisch (ebenfalls ein Strato-Server). Ein Hardware-Problem bzw. Speicherdefekt würde ich ausschließen, da es schon ein sehr großer Zufall sein müssen, dass ein Hardwareproblem nach einem Update auf zwei Servern gleichzeitig auftritt.

Ich würde eher auf eine dämliche Konstellation der Module tippen. Module wurde geupdated und wollen nun nicht mehr mit den alten.

Ich habe das Update ebenfalls mittels YaST installiert. Gibt es eine Möglichkeit das Update wieder von der Platte zu hauen und die alten Versionen einzuspielen? Leider weiss ich nicht genau, welche Pakete/Module YaST genau bei dem Update aktualisiert hat. Dann hätte ich zwar nicht das Update aber wenigstens einen Server der funktioniert.


Grüße
Christian

 

[mbroemme]

Hi,

das sieht danach aus, als wuerde nachdem Update PHP noch auf alten APXS Kram zugreifen, pauschal wuerd ich sagen, mal das PHP gegen den aktuellen Apache neubauen. Das Problem ist danach mit sehr hoher Wahrscheinlichkeit weg.

 

[Rebel2k]

öhm ja: was ist das APXS ?? muss man das kennen?

@ bishbind:

hast du lust das mal zu testen?
Wenn du es hinbekommst wäre ich dir sehr dankbar wenn du n kleines how-to schreiben könntest, da ich mir sowas noch nicht zutraue

greetz
Chris

 

[bishbind]

@Rebel2k:
Es war leider auch nur eine Idee von mir. Ich habe keine Ahnung wo YaST bei dem Update überall rumgespielt hat bzw. wie ich es nachträglich noch herausfinden kann. Deshalb ist auch meine Hoffnung, dass ein anderer hier schon einmal so etwas gemacht hat. Bisher habe ich auch in den Logs von YaST noch keine brauchbaren Informationen gefunden.

 

[bishbind]

Hallo,

ich habe jetzt den Fehler und auch eine Lösung gefunden.

In der Datei /etc/sysconfig/apache2 muss die Modulreihenfolge geändert werden.

Von: ... php4 rewrite ...
Zu: ... rewrite php4 ...

Bei mir sieht die Zeile dann so aus:

APACHE_MODULES="access actions alias auth auth_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir rewrite php4"

Und dann klappt es auch mit mod_rewrite wieder


Grüße
Christian

 

[Rebel2k]

das kanns doch nciht gewesen sein???
es geht jetzt tatsächlich!!!! Wie bist du darauf gekommen?
Ich werd mal beboachten ob es auch stabil läuft n Paar Tage lang!

danke dir!!

 

[Huschi]

In der Datei /etc/sysconfig/apache2 muss die Modulreihenfolge geändert werden.

Das wäre auch mein Vorschlag gewesen.
Denn das Problem taucht in letzterzeit bei fast jedem Suse-User auf. (Das Forum ist momentan voll davon.)

huschi.

 

[Elegantly]

Hallo,

ich habe jetzt den Fehler und auch eine Lösung gefunden.

In der Datei /etc/sysconfig/apache2 muss die Modulreihenfolge geändert werden.

Von: ... php4 rewrite ...
Zu: ... rewrite php4 ...

Bei mir sieht die Zeile dann so aus:

APACHE_MODULES="access actions alias auth auth_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir rewrite php4"

Einer meiner Linux-Server mit SUSE 9.3 zeigt seit kurzem den gleichen Fehler. Christian's Workaround half bei mir leider nicht. Ich konnte das Problem lösen, indem ich die installierten Apache2- und PHP-Pakete durch die RPMs auf den SUSE-Installationsmedien ersetzte. Nach einem Neustart des Apache-Servers funktionierten PHP-Webseiten wieder.