Debian Sqeeze PHP 5.3.3-7 + fcgid = segfault

[Tristan]

Hallo zusammen,

ich habe da ein delikates Problem mit einem Magento, bzw. mit meinem Apachen im Allgemeinen.

Im error.log finden sich beim Aufruf des Backends massig folgende Fehler. Browserseitig kommt es launenartig entweder zu einem 500er, oder einem 304er.

Code: Select all

child pid 5436 exit signal Segmentation fault (11)

Zum Hintergrund:
Betreffende Installation lief über Jahre problemlos auf einem Lenny mit prinzipiell der gleichen Konfiguration. Auf Grund einer defekten HDD waren wir nach der Neuinstallation gezwungen auf Squeeze zu migrieren.

Zum Einsatz kommt, wie auf dem ursprünglichen System, Plesk 10.4.4. Das logfile für den betreffenden vhost zeigt keine Fehler.
Der Fehler besteht auch mit mod_php. Die geladenen Module sind allesamt heutzutage üblicher Standard, entsprechen der Standardkonfiguration von Plesk.

Das System ist aktuell, und entspricht dem Auslieferungszustand des Hosters.

Sämtliche anderen gehosteten Projekte arbeiten fehlerfrei.

Ideen, Vorschläge, Tipps?

LG
Tristan

[ddm3ve]

viewtopic.php?f=87&t=53764

Dieser Diksussion bzw. meiner Antwort darauf entnimst Du das Problem und die Ursache.

Installiere nach Möglichkeit ein nacktes System ohne php, fastcgi apache etc. etc.

Lade Dir die Installationsdateien von Plesk herunter und versuche alles notwendige Über Plesk zu beziehen. Wenn er bei der Installation Dinge schon auf dem System vorfindet, dann brich die Installation ab und entferne die Pakete.
-> Das ist zwar kein Garant dafür, dass die Plesk Pakete alle i.O. sind und tadellos funktionieren. Aber es mindert Indifferenzen einer Installation aus heterogenen Quellen der Installationspaketen.

[Tristan]

Hi ddm3ve,

vielen Dank für die Antwort. So wäre im Normfall mein Vorgehen gewesen. Leider hatte ich den Prozess nicht veranlasst und die Installation wurde durch den Hoster vorgenommen.

Das Problem ist, dass das System produktiv läuft, und ich schlecht die Notwendigkeit einer weiteren mehrstündigen Downtime verkaufen kann. *seufz* Zwickmühle.

So wie ich das sehe, wurden die debianeigenen Pakete schlichtweg beibehalten und Plesk wurde drübergebügelt. Äußerst ärgerlich, da man eigentlich glauben sollte, ein Hostinganbieter müsse es besser wissen. :/

Ich werde wohl den Erwerb einer zweiten Plesk-Lizenz nahelegen, um eine Testumgebung betreiben zu können.

Mal am Rand gefragt: Bei späteren Updates ist es wohl generell ratsam, die von Plesk mitgebrachten Pakete auszuschließen?

LG
Tristan

[ddm3ve]

Das ist ein generelles Problem mit solchen Produken.
Ein distupdate updated natürlich nicht die von Plesk instalierten Pakete.
Woher auch, die wurden ja manuell installiert und sind nicht über die Repositories verfügbar.
Nachteilig sieht es leider mit den Security Patches durch Paralells aus.
Im Idealfall, will man seine Pakete über die Distribution besorgen, geht hier aber das Risiko etwaiger Inkompatibilitäten ein.

Quasi eine Gretchenfrage, welcher der sauen Äpfel darf es sein.
Auch wenn ich die Anforderung durch die Endkunden nur zu ut kenne und mir den einen oder anderen vergrault habe, weil ich konsequent auf Adminpannels verzichte. Ich kann seither besser schlafen.

[Tristan]

Auch wenn ich die Anforderung durch die Endkunden nur zu ut kenne und mir den einen oder anderen vergrault habe, weil ich konsequent auf Adminpannels verzichte.

Hehehe, ja, wo ich kann, ziehe ich das auch vor. An dieser Stelle gibt es leider wiederum eine Menge absolut unbedarfter Endkunden, und die IT-Abteilung in der jetzigen Form, wäre mit dem administrativen Aufwand wohl eindeutig überfordert. *seufz*

Aber etwas Gutes hatte die ganze Angelegenheit dennoch: Einsichtsbildung hinsichtlich der Notwendigkeit einer kompletten Restrukturierung der absolut chaotisch gewachsenen Serverlandschaft. Allein das Fehlen ausreichend dimensionierter Standby-Server treibt einem die Sorgenfalten auf die Stirn. Und an anderer Stelle vergammeln Boliden, die im Peak nicht einmal auf 5% Last kommen. *verleiert die Augen*

Nachteilig sieht es leider mit den Security Patches durch Paralells aus.
Im Idealfall, will man seine Pakete über die Distribution besorgen, geht hier aber das Risiko etwaiger Inkompatibilitäten ein.

Hier genau liegen die Hintergründe meiner etwas unbedarften Frage. Auch wenn sich meine Erfahrungen mit Plesk auf Grund natürlicher Abneigung arg in Grenzen halten, habe ich den Eindruck gewonnen, dass die Burschen bei Parallels im Vergleich mit den Distributoren bisweilen ziemlich träge sind, im Zweifelsfall ihre Hände gern mal in Unschuld waschen. Allein die Menge gänzlich unbeantworteter Threads im Support-Forum spottet jeglicher Beschreibung. :S

Auf jeden Fall danke ich dir für deine Antwort, die ich ungemein hilfreich fand.

Schönes WE noch
Tristan

[Tristan]

Hier ist wohl mal ein Statusupdate fällig, weil, zumindest für mich, ganz interessant.

Die ganze Geschichte hat sich ja noch etwas hingezogen.

1. Neuinstallation Debian ohne Plesk. Plesk nachinstalliert, vorher alle Pakete gelöscht, die Plesk mit sich bringt. Zwangsweise den PHP5.3-Support von Plesk installiert.
== segfault

2. Hosterwechsel: Centos-Template mit Plesk, wieder zwangsweise den PHP5.3-Support installiert.
== segfault

3. Kunden überredet, auf Plesk zu verzichten: Das ganze System gecleaned, und Dank erforderlichem PHP5.3 aus EPEL+Remi-Repos die notwendigen Pakete installiert, selbst konfiguriert.
== läuft

Nö, läuft nicht nur, sondern aus unerfindlichen Gründen hat sich der Ressourcenbedarf unter haargenau den gleichen Bedingungen halbiert, was ich mir nicht recht erklären kann, da ich im Wesentlichen die gleiche Konfiguration verwende.

Fazit:
Ungedeih und Verderben möge über die Entwickler bei Parallels ob ihres zweifelhaften Tuns kommen.

Der PHP5.3-Support von Plesk ist besten Falles als eperimentell zu bezeichnen, und, vertrau keiner Config, die du nicht selbst vermurkst hast.

Liebe Grüße
Tristan

[ddm3ve]

Fazit:
Ungedeih und Verderben möge über die Entwickler bei Parallels ob ihres zweifelhaften Tuns kommen.

Darf ich in das Abendgebet noch einzelne Personen hinzu nehmen?

Danke fürs Update.
Wenn php nun von dir instaliert wurde, wäre es ggf. auch mal ein Test Wert danach Plesk drüber zu instalieren.
ggf. die Installation von Plesk PHP Modulen verhindern / abbrechen.

[Tristan]

Gern, nimm hinzu wen auch immer du magst.

Die Installation von Plesk erspare ich mir. Betreffendes Projekt haben wir auf ein eigenes Blech ausquartiert. Der Administrationsaufwand hält sich demzufolge in Grenzen.