Debian6/Apache2/Magento - Rätselhafter Error 500 ohne Logeintrag

[Daaron]

Evtl. hat ja einer von euch eine Idee, woran es liegen könnte und wie ich den Mist wieder zum Laufen bekomme...

Einer unserer Webserver (aktuelles Debian 6 innerhalb einer VM in ESXi) hat sich diese Woche durch Überlastung kurz verabschiedet, zu retten war er nur über n Reset. Die Kiste fuhr sauber wieder hoch, und es läuft fast alles wieder perfekt... bis auf eines: Ein einzelnes Web auf dem Server, ein Magento 1.6.1, will auf den Tod nicht.

Der VHost läuft über Apache mod_suphp, hat ne künstlich angehobene max_execute_time (brauchts bei Magento einfach) und n erhöhtes Speicherlimit.
Rätselhafter Weise geht der Admin-Bereich perfekt, man kann Artikel verwalten, im CMS-Bereich rumkritzeln, den Index neu aufbauen,... Das Frontend hingegen liefert stur einen Error 500 mit ner "unerwarteten Bedingung". Ich hatte zwar schon an anderen Stellen mit Error 500 zu tun, da waren es aber wahlweise Rechte oder n Defekt in der .htaccess.... jedenfalls waren es immer Fehler, die auch irgendwo in einem Log aufgetaucht sind. Dieser spezielle Error 500 hingegen tarnt sich. Die blöde Sau taucht nicht im VHost-eigenen error.log auf und auch in /var/log/apache2/ ist nichts. Das einzige, was zu sehen ist, sind die 500-Einträge im access.log. Die helfen mir aber nicht wirklich weiter...

Was ich ausschließen kann:
- Fehler innerhalb der PHP-Scripte oder der Datenbank des Shops: Eine Kopie des Shops läuft wunderbar z.B. auf meiner lokalen Kiste.
- massive Kasper im Apache oder mod_suphp: Andere php-basierte VHosts auf der Maschine laufen korrekt.... und auch das Backend vom Shop will ja

Jemand ne kreative Idee, woran es liegen kann? Hatte schon mal jemand von euch n E500 ohne Log-Eintrag?

 

[tifa]

Du sollst im Magento log nachgucken was Error 500 verursacht

 

[chr1zZo]

Ja die 1.6er Versionen von Magento waren einfach nur Instabil. Probiers doch mal mit der 1.7.1 die läuft stabiler. Ist leider ein sehr anfälliger Shop. Ich hatte mal 5 Magento Shops aufgesetzt, 4 davon sind völlig zerstört nur dadurch das ich Addons eingespielt habe..... (die ja angeblich kompatibel sind usw). Bisher lebt nur 1 Store davon und das Stabil. Ist leider sehr schade, deswegen arbeite ich gerne mit anderen Systemen die nicht so rum zicken.

 

[Daaron]

Das Magento-Log sagt auch nix. Der system.log verzeichnet n paar recoverable errors, das tut es aber schon ewig (und tut es auch auf der momentan im Einsatz befindlichen Ersatz-Maschine). Das exception.log glänzt durch Leere.

Ein Upgrade auf 1.7 dürfte auch keine Option sein. Mein Chef reißt mir den Kopf ab, wenn ich sowas vorschlage. Da sind zu viele frickelige Addons drin, die teilweilse sogar nur für 1.5 waren, aber glücklicherweise unter 1.6 auch laufen. Und wie gesagt, das Web lief vor dem Server-Crash stabil und es läuft auf anderen Maschinen ebenfalls.

 

[tifa]

Bau dir ein dev umgebung wo alles testen kannst

Oder mal an einem anderen server oder vrs ausprobieren

 

[Daaron]

Wenns so einfach wäre... Der Mist läuft ja auf meinem Büro-PC (Ubuntu 12.04 x64) perfekt, und auch auf einem anderen unserer Webserver läuft es. Es läuft nur eben nicht auf der Maschine, auf der wir es aktuell gern hätten und wo es einige Monate lang perfekt lief. Und es verabschiedet sich halt mit Error 500 ohne jegliche Log-Einträge.

Die Frage ist also: Was kann ein Server-Crash (durch ne Mischung aus Bad Bots und nem schlechten Cronjob) kaputt machen, dass NUR das Frontend von einer Magento-Installation aussteigt. Andere PHP-basierte Sites auf dem Server laufen. Ein anderes Magento (1.7.1), dass ich zum testen installiert hab, funktioniert auch. Das Backend der betroffenen Site funktioniert auch korrekt.... Macht einfach keinen Sinn.

Die Checksums der verschiedenen Pakete des Servers sehen übrigens gut aus. Wär ja zu leicht gewesen, wenn einfach irgend eine obskure PHP-Library, die nur vom Magento Frontend genutzt wird, eine Macke hätte.