WSOD, weiße Seite
Eingetragen von gargamel (127)am 17.11.2009 - 15:42 Uhr in
Drupal 6.14, Views 2.7, Trackback 1.x-dev, Ubercart 2.0 mit einem uc_order Patch, Recent_Comments
Das WSOD Syndrom wie ich es bereits nenne, treibt mich seit einigen Tagen an den Rand der Verzweiflung. Habe bereits sämtliche Hinweise hier und in drupal.org durchgelesen, aber so richtig scheint da keiner ein Mittel zu haben, da wird meißt herumgedoktert.
Problem bei mir: Die weiße Seite kommt sporadisch und unerklärlich. Es langt, wenn man einen internen Menülink aufruft, schon ist mein TFT weiß wie die Flieder, kein Quelltext, nichts, nada.
Versuche ich hingegen andere html Seiten (Verifizierungsseiten von google etc..) aufzurufen die innerhalb des Drupal Verzeichnisses liegen, werden die aufgerufen. Alle anderen URL´s, egal ob mit oder ohne alias, innerhalb der Drupal-Installation hingegen führt zu nichts. Habe die .htaccess Datei, index.php und index.html umbenannt, einzeln, gesamt, hat auch nichts geholfen.
Zum Schluß kam ich auf die Idee, die Module die ich zuletzt installiert hatte, aus der System-Tabelle der Datenbank zu deaktivieren, also Status auf 0. Auch das hat nicht geholfen. Ich hatte bis gestern das gleiche Problem schon mal, konnte es aber Mithilfe des Serveradmins wieder zum laufen bringen. Er hatte wohl den Apache neu starten lassen. Nach nur wenigen Stunden, stehe ich nun wieder vor dem gleichen Problem, wieder eine weiße Seite und ich stehe wie ein Ochs vorm Berg und muss auf den Admin warten. Über Plesk kann ich zwar auf den Error-Log zugreifen, aber ausser einigen Sachen die mir nicht relevant erscheinen, sehe ich nichts:
[Mon Nov 16 22:55:38 2009] [error] [client 67.XXX.XXX.XXX] File does not exist: /var/www/vhosts/*Drupal/httpdocs/calendar
[Mon Nov 16 22:56:01 2009] [error] [client 67.XXX.XXX.XXX] File does not exist: /var/www/vhosts/*Drupal/httpdocs/calendar
[Tue Nov 17 01:04:20 2009] [error] [client 78.XXX.XXX.XXX] PHP Fatal error: views_db_object::get_item() [function.views-db-object-get-item]: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "views_plugin_display_default" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /var/www/vhosts/*Drupal/httpdocs/modules/views/includes/view.inc on line 1918, referer: http://*Drupal/admin/build/views/edit/comments_recentfront
[Tue Nov 17 01:49:40 2009] [error] [client 67.XXX.XXX.XXX] File does not exist: /var/www/vhosts/*Drupal/httpdocs/content
[Tue Nov 17 01:50:07 2009] [error] [client 67.XXX.XXX.XXX] File does not exist: /var/www/vhosts/*Drupal/httpdocs/content
Das letzte mal hatte ich es heute früh um genau 1:43 Uhr.
Frage: Wer hat sonst noch so ein Problem. Eventuell ist es ja zeitlich einzugrenzen und kann auf ein bestimmtes Modul zurück geführt werden. In letzter Zeit habe ich wie gesagt Trackback und die Sofortüberweisung-Modul für Übercart installiert, ansonsten noch den Patch für uc_order der mir Fehler ausgab, das mit dem Patch beseitigt war.
Das php_ini hat es einigen richtig angetan, so scheint es mir. Was sogar dazu führt, das man diese bis auf mittlerweile auf über 100M treibt oder die Zeit sogar erhöht. Bringt denn das was und wieso ist Drupal bzw. die Module selbst teilweise solche Speicherfresser? Gibt es eventuell ein Modul, mit dem ich dies vergleichen, skalieren, testen und sehen kann, welche Module eventuell für einen php Blackout neigen um damit von vornherein solche Speicherfresser auszuschließen? Bis vor kurzem hatte ich kein Problem damit, ausser das ich ab und an mal die Fehlermeldung bekam, das ich die php_ini mal ausgereizt habe und der Bildschirm aus einer Zeile bestand. Das aber ist schon heftig. Man steht vor einem Bildschirm, das dir nichts sagt. Für einen Laien ist das ein erhebliches Problem.
- Anmelden oder Registrieren um Kommentare zu schreiben
Was sagt denn Dein PHP-Log
am 17.11.2009 - 16:05 Uhr
Was sagt denn Dein PHP-Log zu dem Thema? Das riecht nach zu wenig Memory oder Rechenzeit überschritten, da es nur sporadisch auftritt.
Beste Grüße
Werner
PHP Memorylimit ist bei 64,
am 17.11.2009 - 16:37 Uhr
PHP Memorylimit ist bei 64, ist nicht gerade wenig. Die Zeit kenne ich nicht, müsste ich noch in Erfahrung bringen. PHP-Log muss ich auch anfragen.
Ich habe folgende Dienste auf dem Plesk:
Dienste
Apache ASP-Unterstützung Nein
SSI-Unterstützung Nein
PHP-Unterstützung Ja (Apache-Modul , PHP 'safe_mode' aktiviert)
CGI-Unterstützung Ja
Perl-Unterstützung Ja
Python-Unterstützung Nein
FastCGI-Unterstützung (erforderlich für Ruby on Rails)
gargamel schrieb PHP
am 17.11.2009 - 16:54 Uhr
PHP Memorylimit ist bei 64, ist nicht gerade wenig. Die Zeit kenne ich nicht, müsste ich noch in Erfahrung bringen. PHP-Log muss ich auch anfragen.
Ich hoffe es sind wenigstens MB :P
64 MB können schnell mal zu eng werden. Entsprechende Posts hast du ja bereits gefunden, ebenso wie die notwendigen Gegenmaßnahmen. Es gibt keine Übersicht welche Module wieviel Speicher verbrauchen, eine solche kann es aus diversen technischen Gründen auch nicht geben, erstrecht nicht allgemeingültig für jede Serverumgebung.
Klar, wenn dir dein Ferrari den letzten Cent an der Zapfsäule aus der Brieftasche zieht, kannst du überlegen das Auto zu wechseln, weniger zu fahren oder auf der Kupplung stehend alles im 6. Gang zu machen. Dann macht der Sportwagen aber keinen Sinn mehr. Willst du ihn seiner Natur entsprechend betreiben, musst du eben auch die zugehörigen laufenden Kosten in Kauf nehmen. Das verhält sich mit Software nicht anders.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Sind MB ;)
am 21.11.2009 - 18:08 Uhr
Der Hostbetreiber unterhält selbst einige CMS Seiten sowie zwei Drupal Seiten auf dem gleichen Server, daran dürfte es nicht liegen?!
Nun ja, ich habe jetzt mal die Error-Log beobachtet:
[Thu Nov 19 20:08:07 2009] [error] [client 78.42.54.104] PHP Fatal error: Call to undefined function gibtsnicht() in /var/www/vhosts/domainname/httpdocs/test.php on line 3
[Thu Nov 19 20:20:59 2009] [error] [client 67.218.116.133] PHP Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/ubercart__/uc_catalog/uc_catalog.pages.inc' (include_path='.:') in /var/www/vhosts/domainname/httpdocs/includes/menu.inc on line 346
[Thu Nov 19 21:27:45 2009] [error] [client 67.218.116.133] PHP Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/ubercart__/uc_catalog/uc_catalog.pages.inc' (include_path='.:') in /var/www/vhosts/domainname/httpdocs/includes/menu.inc on line 346
[Thu Nov 19 21:31:43 2009] [error] [client 67.218.116.133] PHP Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/ubercart__/uc_catalog/uc_catalog.pages.inc' (include_path='.:') in /var/www/vhosts/domainname/httpdocs/includes/menu.inc on line 346
[Thu Nov 19 22:07:33 2009] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Thu Nov 19 22:07:33 2009] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Thu Nov 19 22:15:56 2009] [error] [client 188.99.223.98] PHP Fatal error: Call to undefined function drupal_get_headers() in /var/www/vhosts/domainname/httpdocs/modules/dtools/wsod/wsod.module on line 102
Die test.php ist von mir kurz angelegt gewesen, ubercart__ habe ich kurz umbenannt (Module einzeln aus der Installation genommen), WSOD-Modul habe ich auch installiert. Ich stehe total auf dem Schlauch, der Hostbetreiber ist im Moment nicht erreichbar.
Wie kann man den eigentlich den Cache komplett löschen, z.B. über Mysql. Sind das die Tabellen
cache
cache_block
cache_content
cache_filter
cache_form
cache_location
cache_menu
cache_nodewords
cache_page
cache_uc_price
cache_update
cache_views
cache_views_data
oder ist das unter system drin?
Ist erledigt
am 26.11.2009 - 23:43 Uhr
für alle, die das gleiche Problem haben, eventuell ein Lösungsweg. Mir hat es geholfen. Seitdem läuft Drupal einwandfrei, habe den Tip hier in drupalcenter gefunden, find ihn aber nicht mehr.
Falls man eigene Patches in Contrib-Modulen hat, dies berücksichtigen. Ich habe alles frisch runter geladen und aufgespielt, danach aktiviert. (Contrib Module diesmal in sites/all/modules, da ich das früher in den normalen modules Ordner abgelegt hatte)
Möglich das eine php entgegen der Drupal-Topologie in einer der Dateien geschlossen wurde bzw. ein Fremdzeichen eingeschlichen hat, wer weiß.