Beim Aufsetzten eines OXID (Backup) Shops mussten wir uns vor Kurzem mehrere Stunden mit einem Apache Segmentation Fault Error herumärgern.
[Sat Oct 17 23:57:45 2015] [notice] child pid 13850 exit signal Segmentation fault (11)
Die Details möchten wir euch an dieser Stelle erläutern, um auch evtl. anderen Problemsuchendenden eine Hilfestellung geben zu können.
Wie kam es dazu?
Nach der Installation eines neuen Backup-Servers mit einer Puppet-Konfiguration (identische Konfiguration wie der Live-Server) kam beim Aufruf des Shops eine weiße Seite. Also sind wir erst einmal die „üblichen Verdächtigen“ wie Datenbank-Verbindung, Verzeichnis-Schreibrechte, … durchgegangen, leider ohne Ergebnis. Auch in den „Ich erhalte im Shop eine weiße Seite, was nun?“ FAQ von D3 sind wir nich fündig geworden.
Wie debuggen?
Nachdem wir sicher waren, dass der Shop nicht das Problem sein kann, sind wir detailierter ins Debugging eingestiegen. Beim Deaktivieren einzelner Apache-Module hatten wir schliesslich Erfolg, sobald der IonCube-Loader inaktiv war. Jedoch hat uns das natürlich nichts genutzt, da dieser zum Betrieb des Shops (Drittanbietermodule) benötigt wird. Nach weiteren Tests und das Durchlesen vieler Forenbeiträge sind wir dann auf die Idee gekommen einen Stracktrace des Webserver-Aufrufes mitzuloggen.
mkdir /strace; ps auxw | grep apache2 | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r
Als Ergebis wurde ein LOG-File geschrieben (welches sehr schnell sehr groß werden kann), was uns jedoch den entscheidenden Hinweis lieferte (siehe Screenshot): es wurde mehrfach versucht, eine Datei „ac_module.php“ zu laden, welche jedoch physikalisch nicht verfügbar war. Nach vielfachen Versuchen hat der Apache Webserver „aufgegeben“ und einen Segmentation Fault im Apache-Errorlog dokumentiert.
Was war der Fehler?
Zum Debuggen eines Shop-Problems wurde das Modul oxid-module-internals im Live-Shop installiert, jedoch nicht ins GIT-Repository eingecheckt. Beim Einspielen des Shops auf dem Backup-Server wurde jedoch eine aktuelle Kopie der Live-Datenbank verwendet, in welchem das Modul aktiviert war. Durch das unvollständige Repository fehlten jedoch die eigentlichen Moduldateien.
Normalerweise hat OXID mit der oxModule-Klasse auch eine interne Logik, um fehlerhafte Module (wie z. B. in diesem Fall) automatisch zu deaktiveren. Nachdem das oben genannte Modul jedoch auch genau die gleiche Klasse oxModule erweitert, greift diese nicht und es kam zum oben genannten Fehler.
