Drupal: Der weiße Bildschirm des Todes

Wenn man beim Anschauen einer Website, die mit dem Content Management System Drupal betrieben wird, nur noch eine weiße Seite im Browser zu sehen bekommt, steht man erst einmal wie Ochs vorm Berg. Das Phänomen ist nicht ganz unbekannt und auch nicht rein Drupal-spezifisch und wird im Fachjargon als WSoD (White Screen of Death) bezeichnet.

In PHP-Anwendungen im Allgemeinen und Drupal im Besonderen kann dieser Fehler unter verschiedenen Bedingungen auftreten. Grundsätzlich bekommt man immer dann eine leere weiße Seite zu sehen, wenn die Ausführung des PHP-Skripts durch einen Fehler unterbrochen wurde, noch ehe eine Ausgabe an den Browser gesendet wurde.

Hier ein paar mögliche Ursache und wie man sie aufspürt:

Das PHP Skript benötigt mehr Arbeitsspeicher, als ihm laut Konfiguration zur Verfügung steht:

In diesem Fall findet man im Fehlerprotokoll des Webservers (mglw. nur via FTP beim Hoster abrufbar) in der Regel Einträge dieser Form:

Fatal error: Allowed memory size of [Zahl] bytes exhausted (tried to
allocate [Anzahl] bytes) in [Pfad_zum_Skript] on line [Zeilennummer]

Der Hintergrund ist, dass PHP in der Regel derart konfiguriert wird, dass ein Skript bei der Ausführung nur eine einstellbare maximale Menge an Hauptspeicher benutzen kann. Dies soll verhindern, dass ein einzelnes Skript versehentlich oder mutwillig sämtlichen Speicher des Servers an sich reißt. Zuständig hierfür ist in der Konfigurationsdatei der Parameter “memory_limit“. Je nach Servereinstellung / Hoster kann man diesen für eigene Skripte ggf. auch über eine .htaccess Datei verändern. Details zum Vorgehen erfährt man von seinem Hoster und an dieser Stelle.

Allgemein gesprochen erhöhen sich die Speicheranforderungen von Drupal mit der Anzahl aktivierter Module und ggf. mit der Menge an Daten in der DB. Bei eigenem Code sollte man wie immer nicht zu verschwenderisch mit Ressourcen umgehen.

Irgendwas geschieht noch ehe die ersten HTTP Response Header gesendet werden

Ein Webbrowser fordert eine Ressource (z.B. eine Seite, ein Bild, eine CSS Datei, etc.) an, indem er über das HTTP Protokoll (oder korrekt: das HTT Protokoll) eine Anfrage (engl.: request) an den Server abschickt. Dieser beantwortet mittels einer sog. HTTP Response (Antwort). Anfrage und Antwort bestehen jeweils aus einem sog. Header, der Verwaltungsinformationen enthält und einem Body, der (optionale) Nutzdaten enthält. Die korrekte Anfrage einer Webseite beantwortet der angefragte Server mit einer Response, die im Body den HTML Quellcode enthält. Der Header enthält dabei Informationen, wie z.B. ob und wie lange die Seite in einem Cache gehalten werden soll, wieviele Bytes die Antwort enthält, wie sie kodiert ist, ob und wie sie komprimiert ist, usw.

Das HTTP Protokoll legt fest, dass der Header als bei Request und Response als erstes gesendet werden muss. Solche Header kann man etwa in PHP auch gesondert erzeugen und werden dem Body dann automatisch vorangestellt. Unter Umständen, oder bei einem Programm(ier)fehler kann es aber vorkommen, dass ein Skript bereits Nutzdaten ausgibt, die der Webserver an den Client zurücksendet, noch ehe das Skript alle Header zusammengestellt hat. In dem Fall setzt es beim Versuch einen weiteren Header zur Antwort hinzuzufügen einen Fehler. Diesen findet man meist auch im Fehlerprotokoll des Webserver, aber auch im Protokoll von Drupal selbst:

Drupal White Screen of Death wegen bereits gesendetem Header

Cannot modify header information -headers already sent

Folgende Ursachen können hier u.a. in Frage kommen:

  • Eine PHP Datei eines Moduls oder die template.php des eingesetzen Templates enthält wenigstens ein Zeichen vor dem PHP-Starttag “<?php”. Vor diesem Tag darf nichts, auch kein Leerzeichen stehen.
  • Eine PHP Datei, z.B. die template.php enthält am Ende ein schließendes PHP-Tag “?>”. Da dies wegen der gegenseitigen Inkludierung der Dateien zu Problemen führen kann, wird die Verwendung von den Drupal Programmierrichtlinien klar untersagt. Auch die entsprechende Fachliteratur erwähnt diesen Umstand gemeinhin.
  • Eine PHP Datei wird zwar UTF-8 kodiert gespeichert, enthält aber ein BOM (byte order mark). Ein guter Editor lässt sich auf die Verwendung einer Standardkodierung festlegen. Zusätzlich kann meist auch angegeben werden, wie Zeilenumbrüche im Text abgebildet werden sollen (CR, LR oder CRLF. Ein sehr guter Editor enthält zusätzlich eine Steuerung ob eine BOM abgespeichert werden soll oder nicht. Für Drupal sollte diese BOM nicht benutzt werden, da sie – obwohl im Editor als lesbares Zeichen meist nicht angezeigt – vom PHP Interpreter wahrgenommen und als auszugebendes Zeichen interpretiert wird.

Einstellung des Encoding in Coda
Einstellung der Kodierung in Coda

Einstellung der Kodierung im Texteditor e
Einstellung der Kodierung im Texteditor e

 

Einstellung der Kodierung im Crimson Editor
Einstellung der Kodierung im Crimson Editor

Wenn der Webserver nicht mehr will:

Es gibt diverse Möglichkeiten seinen Apache Webserver sicherer zu machen. Eine dieser Möglichkeiten ist das Apache Modul ModSecurity. Dieses benutzt einen konfugierbaren Regelsatz. Wird eine Anfrage an den Webserver gestellt, wird diese zunächst von ModSecurity gegen seine Regeln durchlaufen. Schlägt eine oder schlagen mehrere dieser Regeln an, sorgen diese für Warnungen und ggf. Fehlermeldungen im error.log des Webservers und ggf. noch in separaten Logdateien von ModSecurity. Hierin findet sich dann ggf. eine Zeile, die u.a. Angaben wie diese enthält:

[Tue Jul 22 17:38:44 2008] [error] [client 84.187.75.218]
ModSecurity: Access denied with code 501 (phase 2).[id "950005"]
[msg "Remote File Access Attempt. Matched signature <httpd.conf>"]
[severity "CRITICAL"]

Hinter “id” finden wir die ID der auslösenden Regeln, anhand derer diese deaktiviert werden kann. Dazu kann man man sich der Direktive SecRuleRemoveById bedienen, die ModSecurity mitbringt. Über die Konfigurationsdateien von ModSecurity kann man so serverweit Regeln deaktivieren. Deutlich präziser kann man im Apache httpd zu Werke gehen, arbeitet man über die httpd.conf oder .htaccess Datei. Hierzu setzt man die SecRuleRemoveById Direktive einfach in einer passende Apache httpd Core Direktive, wie z.B. File, Directory oder Location und kann so wesentlich präziser nur für einzelnen Verzeichnisse oder Skripte Regeln außer Kraft setzen.

Wenn der Webserver nicht mehr kann:

Besonders hart trifft es denjenigen, dessen Webserver einfach “aussteigt”. Betroffen ist, wer Meldungen ähnlich der folgenden in seinem error.log findet:

[notice] child pid 15336 exit signal Segmentation fault (11)

Bedeutet verinfacht gesagt, dass der entsprechende Webserver-Prozess abgerauscht ist, nachdem er versucht hatte illegal auf einen Speicherbereich zuzugreifen. Sowas kann auch mal ein Hinweis auf defekte oder inkorrekt verwendete RAM-Bausteine sein, allerdings sollten diese Fehler dann auch bei anderen Anwendungen vorkommen und nicht nur beim Webserver. Wahrscheinlicher ist ein Softwarefehler. Dieser kann sich wieder um Kern des Apache, in einem seiner Module oder einer zugrunde liegenden Programmbilbiothek liegen.

In diesem Fall sollte man sich an den Administrator der Maschine wenden. Ist man selbst der Administrator, sollte man checken, ob alle Programme und Bibliotheken auf dem Server auf dem aktuellen Stand sind. Besonderes Augenmerk sollte selbst kompilierten Programmen gelten. Im Gegensatz zu den ferfügbaren Fertigpaketen des Herstellers der verwendeten Linux-Distribution sind diese entsprechend nicht gegen die anderen Bestandteile der Distribution getestet und damit potenziell anfälliger.

Um einzukreisen welches Puzzlestein für den Absturz verantwortlich ist, sollte man einzeln alle nicht benötogten Apache-Module deaktivieren. Bei aktuellen Versionen muss man dazu lediglich die entsprechenden Dateien in /etc/apache2/mods-enabled löschen (keine Angst, es handelt sich nur um symbolische Links) und anschließend den Webserver mit “/etc/init.d/apache2 restart” neu starten.

A propos Webserver neu starten: Oft hilft auch gerade dieses für eine Weile. So kann man sich evtl. etwas Luft verschaffen, bis man genau weiß woran es liegt und die Ursache beheben kann.

Kommentare (17) Schreibe einen Kommentar

  1. Hi Alexander,

    bei mir ist der Bildschirm nicht weiß, sondern voller Fehler! Ich habe mir da was aufgehalst!!! Nun weiss ich überhaupt nicht mehr weiter…..Habe dir die Adresse als URL eingefügt http://localhost/drupal56/

    Bitte melde dich auf meine private Email Adresse wenn möglich…vielen Dank
    Marc

  2. Ja super! Macht Sinn (lach sich tot):::schau mal..vielleicht kannst du mir da ja helfen…habe die Fehler mal hier notiert. Mittlerweile habe ich ein update von 5.6 auf 6.3 gefahren und sehe nun ein wenig von der Seite….

    Also folgende Fehler sind zu lesen:

    Warning: Table ‘drupal56.sessions’ doesn’t exist query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = ‘b9cc9248b61ac99f3dce11764739b9ac’ in C:\xampplite\htdocs\drupal56\includes\database.mysql.inc on line 128

    Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at C:\xampplite\htdocs\drupal56\includes\database.mysql.inc:128) in C:\xampplite\htdocs\drupal56\includes\bootstrap.inc on line 981

    Warning: Table ‘drupal56.cache’ doesn’t exist query: SELECT data, created, headers, expire, serialized FROM cache WHERE cid = ‘variables’ in C:\xampplite\htdocs\drupal56\includes\database.mysql.inc on line 128

    Warning: Table ‘drupal56.cache’ doesn’t exist query: UPDATE cache SET data = ‘a:51:{s:13:\”theme_default\”;s:8:\”theme036\”;s:13:\”filter_html_1\”;i:1;s:18:\”node_options_forum\”;a:1:{i:0;s:6:\”status\”;}s:18:\”drupal_private_key\”;s:64:\”706c1e09eba251d6ff9ac94459386231f24ffde6c96260c01a05de1c2d8da6d4\”;s:10:\”menu_masks\”;a:19:{i:0;i:62;i:1;i:61;i:2;i:59;i:3;i:31;i:4;i:30;i:5;i:29;i:6;i:24;i:7;i:21;i:8;i:15;i:9;i:14;i:10;i:13;i:11;i:12;i:12;i:11;i:13;i:7;i:14;i:6;i:15;i:5;i:16;i:3;i:17;i:2;i:18;i:1;}s:12:\”install_task\”;s:4:\”done\”;s:13:\”menu_expanded\”;a:0:{}s:17:\”update_last_check\”;i:1209043541;s:9:\”site_name\”;s:14:\”Business Group\”;s:9:\”site_mail\”;s:12:\”admin@tm.com\”;s:21:\”date_default_timezone\”;s:4:\”7200\”;s:23:\”user_email_verification\”;b:1;s:9:\”clean_url\”;i:0;s:12:\”insta in C:\xampplite\htdocs\drupal56\includes\database.mysql.inc on line 128

    Warning: Cannot modify header information – headers already sent by (output started at C:\xampplite\htdocs\drupal56\includes\database.mysql.inc:128) in C:\xampplite\htdocs\drupal56\includes\bootstrap.inc on line 582

    Warning: Cannot modify header information – headers already sent by (output started at C:\xampplite\htdocs\drupal56\includes\database.mysql.inc:128) in C:\xampplite\htdocs\drupal56\includes\bootstrap.inc on line 583

    Warning: Cannot modify header information – headers already sent by (output started at C:\xampplite\htdocs\drupal56\includes\database.mysql.inc:128) in C:\xampplite\htdocs\drupal56\includes\bootstrap.inc on line 584

    Warning: Cannot modify header information – headers already sent by (output started at C:\xampplite\htdocs\drupal56\includes\database.mysql.inc:128) in C:\xampplite\htdocs\drupal56\includes\bootstrap.inc on line 585

    Wäre cool um deine Hilfe!!!!

  3. In deiner Datenbank drupal56 fehlen die Tabellen cache und sessions. Der Rest sind Folgefehler.

    Wie du die gelöscht bekommen hast, wird wohl dein Geheimnis bleiben. Versuchs mal mit einer sauberen Neuinstallation. Solltest du bereits Daten im System haben, mach ne parallele Neuinstallation und kopiere die Tabellen cache und sessions von dort rüber in die Datenbank drupal56.

  4. Pingback: Der Juli 2008 - Alexander Langer

  5. Hallo Alexander,

    Ich finde deine Sammlung von Ursachen für den WSoD für Drupal sehr hilfreich. Herzlichen Dank dafür.
    Könnest du noch einen Punkt aufnehmen, der sich mit dem Zend-Problem befasst? (vgl. http://www.drupalcenter.de/node/19181#comment-67657)

    Ich bin schon öfters damit konfrontiert gewesen und es scheint doch auch eine der Standard-Ursachen für den WSoD zu sein.

    hg, goesnow

  6. Hallo,

    bei dem von dir geschilderten Fall gibt PHP aber eine Fehlermeldung im Browser aus. Entsprechend handelt es sich in dem Fall auch nicht um einen WSOD.

  7. hey,
    bei mir war es die unter mac os x durch “finder”-kopieren fehlende .htaccess, die den wsod auslöste. dies passierte am erst am abschluss der installation. trotzdem danke für deine tipps.

  8. Dass es dabei zum WSOD kommen kann, war mir neu. Generell passiert es vielen, die nicht wissen, dass der Finder nichts kopiert, was er nicht anzeigt und dass man darum besser den entpackten Ordner im Ganzen kopiert und umbenennt, anstatt seinen Inhalt zu kopieren.

  9. Hallo

    Installation hat alles geklappt. Ich rufe die Seite auch das funktioniert. Ich drücke “Administer” und zack kommt der WSOD. Der Quelltext ist bis auf den Header leer.

    Was kann ich da tun?

    Danke

  10. Hast du mal ins Fehlerprotokoll vom Webserver geschaut? Wenn du keinen direkten Zugriff auf die Datei, etwa per FTP hast, haben die meisten Hoster im Verwaltungsbereich eine Möglichkeit die letzten x Zeilen des Logs ausgeben zu lassen. Ansonsten müsstest du mal beim Support nachhaken.

    Als erstes würde ich im Webspace mal eine Datei info.php mit dem Inhalt < ?php phpinfo(); ?> anlegen, im Browser aufrufen und checken, wie das Memory Limit eingestellt ist.

  11. Das sollte für eine Grundinstallation reichen, ist im Grunde aber schon etwas eng. 64 wären nicht schlecht. Schau mal ob du bei deinem Hoster das Limit durch eine .htaccess Datei oder in der Verwaltung anheben kannst.

  12. Ich habe eine Anfrage bei evanzo laufen. Ich meld mich bei Antwort. Danke für deine Hilfe.

  13. Also im error log steht leider nichts dazu.
    Habe auch die Datei wsod_emergency.php hochegeladen. Aber wenn ich diese aufrufe, dann erhalte ich auch einen WSOD.
    Joomla läuft in einem anderen Verzeichnis problemlos.

  14. Moment, du schreibst eingangs, “Der Quelltext ist bis auf den Header leer.”, d.h. die vermeintlich leere Seite enthält aber einen korrekten Drupal-HTML-Head?? In dem Fall ist kein klassischer WSOD..

  15. Hallo Alexander, ich habe Drupal 7.26 auf einem Webspace laufen und schon eine ganze Menge an Views und Modulen installiert. Zwei Mal ist es nun passiert, dass nach dem Update von Modulen ich mich nicht mehr anmelden kann. Ein weisser Bildschirm nach dem Login..nichts weiter. Ich habe den Verdacht, dass beim Update – zuletzt war es das Devel-Modul – die Datenbank zerschossen wird. Beim ersten Mal habe ich Drupal komplett neu installiert. Aber das kann ja nicht Dauerzustand sein. Hast Du eine Idee?
    Danke im Voraus für die Hilfe
    Kekko

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.