White Screen of Death (Drupal)

Uit De Vliegende Brigade
Ga naar: navigatie, zoeken

Belangrijkste oorzaken

Belangrijkste oorzaken van een White Screen Of Death (WSOD):

  • Geheugenproblemen
  • Time-out
  • Lege database: Als ik een site migreer, en ik pas settings.php aan overeenkomstig de nieuwe situatie, maar de betreffende database is nog leeg, krijg je een WSOD. Drupal heeft niet door dat het geen nieuwe installatie betreft.
  • Fouten bij bijwerken van modules

Diagnose

1. Bekijk het PHP-foutlog

tail /var/log/php/error.log

2. Overig

Als het log niets vermeldt, is de storing vermoedelijk eerder een hosting-probeem dan een Drupal-probleem. Zie Site wordt niet weergegeven (Apache) in dat geval.

  • PHP-foutmeldingen aanzetten: Zet Drupal error reporting aan met foutmeldingen naar het scherm, indien mogelijk: Configuration » Development » Logging and errors
  • PHP-foutmeldingen aanzetten: Zet error reporting aan in PHP
  • Controleer of database-connection-string klopt
  • Verifiëer dat er geen verloren .htaccess-bestand rondzwerft.

Zie ook:

Casus sep. 2013: Productie-omgeving + taxonomie-import

Probleem

In september 2013 kreeg ik een WSOD op een Drupal 6-webwinkel op een productiesite tijdens importeren van een taxonomie. De directe oorzaak was vermoedelijk een geheugenprobleem. Zelfs na verwijderen van het import-bestand en de bijbehorende module, bleef het WSOD.

Aanvullende gegevens

  • Misschien houdt Drupal ergens in de database state vast, zodat-ie nog steeds weet dat-ie bv. nu op 'stap 4' zit
  • Ik kan de huidige database middels phpmyadmin kopieren naar een locale machine. Crasht-ie dan nog steeds?
  • Ik kan ook gewoon de meest recente backup terugzetten. Die was met Backup & migrate gemaakt, maar ik kan 'm wellicht met phpmyadmin overloaden. Wel opletten dat ik dat kan terugdraaien in geval van complicaties
  • Watchdog-log was niet benaderbaar (www.example.com/admin/reports/dblog)
  • Hier wordt uitgelegd hoe je op database-niveau modules kunt uitzetten.

Acties

  • Cache legen mbv. PHPMyAdmin: Cache (geen resultaat)
  • update.php nog een keer uitgevoerd: De pagina werkte wel, maar het commando had geen resultaat
  • In tabel {system} de volgende modules & theme uitgezet: taxonomy, pathauto, poormanscron, Garland-aangepast en uc_catalog. Deze laatste was de boosdoener. Nu deed de site het weer.

Weer een werkbare site opbouwen:

  • update.php nog een keer aangeroepen: Geen nieuwe gebeurtenissen
  • cron aangeroepen: Ok
  • Theme Garland-aangepast geactiveerd: Ok

Bronnen

Casus: Sep. 2013: Bijwerken FileField-module

Probleem

In sep. 2013 een WSOD gekregen na bijwerken van modules naar de volgende versies van een Drupal 6-webwinkel:

  • Backup & migrate 2.7
  • Captcha 2.5
  • Filefield 3.11
  • ImageField 3.11

Acties

  • Via phpMyAdmin de betreffende modules uitgezet + steeds tussentijds getest. Probleem verdween na uitzetten FileField
  • FileField daarna op een grondigere manier bijgewerkt: Map op de server leeggemaakt en bestanden die al waren uitgepakt, daarheen gekopiëerd. Probleem verdwenen.

Oorzaak: Kopiëren rechtstreeks vanuit archiefbeheer-programma

Bij de eerste keer bijwerken had ik de inhoud van de modules rechtstreeks vanuit het zip-bestand met drag-en-drop naar de betreffende mappen op de server gesleept, waarbij bestaande content werd overschreven.

Casus: Feb. 2014: Lege Ubercart-factuurschermen

  • Dit gebeurde na update van Ubercart-site
  • Het betreft de facturen die je kunt afdrukken vanaf Administer › Store administration › Orders › Order xyz
  • Deze facturen worden hoogstwaarschijnlijk gevormd dankzij sjablonen in sites/default/modules/ubercart/uc_order/templates

Oorzaak

We gebruiken aangepaste order-sjablonen. Voorafgaand aan een update maak ik een kopie van de betreffende bestanden (bv. uc_order-customer.tpl.bk01-goed.php) en na de update, plaats ik het eigen sjabloon weer terug.

Bij het terugplaatsen had ik een tikfout gemaakt. Blijkbaar geeft dat een leeg scherm. Ik had het gevonden door de sjablonen-map te vergelijken met die van een webwinkel waar de facturen wel functioneerden.

Casus sep.2014: Met geweld een module verwijderd

Via FTP had ik een module verwijderd zonder deze eerst te un-installen. Na aanzetten foutmeldingen via .htaccess was dit de foutmelding:

Fatal error: Call to undefined function uc_vat_menu_title() in /var/www/vhosts/example.com/httpdocs/includes/menu.inc on line 506

Mbv. een database-hack de verwijzing in tabel System verwijderd. Helaas: Maakt geen verschil

Oplossing

Aan een willekeurige geactiveerde module toegevoegd:

function uc_vat_menu_title(){}

Daarna deed de site het weer --> Cache doorgespoeld --> Functie verwijderd.

Casus nov. 2014: /var/log/php/error.log bood uitkomst

  • Log-fouten naar het scherm laten schrijven: Nog steeds WSOD
  • php.ini aangepast: Nog steeds WSOD (ook na herstart Apache)
  • Wat hielp:
    less /var/log/php/error.log

Probleem

[22-Nov-2014 15:25:06 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted 
(tried to allocate 72 bytes) in /home/strompf/public/example.com/public/includes/common.inc 
on line 3101

Aanvullende gegevens

  • 134217728 bytes = 2^27 bytes = 128 'oude' megabytes = 128 mebibytes = 128 MiB [1]
  • Betreffende regel in php.ini:
    memory_limit = 128M

Oplossing

php.ini:

memory_limit = 1024M

Alleen een verhoging naar 256M gaf dezelde fout en ook dezelfde melding in het logboek.

Herstart Apache:

sudo service apache2 restart

Opermerking

Er komt een moment dat ik de VPS moet upgraden. Ik merk het wel aan de snelheid.

Casus jan. 2015: /var/log/php/error.log bood uitkomst

Diagnose

Commando

less /var/log/php/error.log 

werkte onvoldoende, want te veel log-entries. Maar

less /var/log/php/error.log | grep example.com

werkte perfect.

Oorzaak

Het leek nogal op deze foutmelding: Unknown on line 0 Fatal error. Inderdaad: Rechten stonden niet goed:

drwxr-xr-x 10 root    root     4096 jan  3 14:29 ./
drwxr-xr-x  5 root    root     4096 jan  2 15:43 ../
-rwx------  1 strompf strompf 47028 jan  2 17:38 CHANGELOG.txt*
-rwx------  1 strompf strompf  1023 jan  2 17:38 COPYRIGHT.txt*
-rwx------  1 strompf strompf   206 jan  2 17:38 cron.php*
drwx------  2 strompf strompf  4096 jan  2 15:52 includes/
-rw-r--r--  1 root    root       63 jan  2 15:43 index.html
-rwx------  1 strompf strompf   923 jan  2 17:38 index.php*
-rwx------  1 strompf strompf  1269 jan  2 17:38 INSTALL.mysql.txt*
-rwx------  1 strompf strompf  1011 jan  2 17:38 INSTALL.pgsql.txt*
-rwx------  1 strompf strompf 47845 jan  2 17:38 install.php*
-rwx------  1 strompf strompf 15572 jan  2 17:38 INSTALL.txt*
-rwx------  1 strompf strompf 18092 jan  2 17:38 LICENSE.txt*
-rwx------  1 strompf strompf  1867 jan  2 17:38 MAINTAINERS.txt*
drwx------  3 strompf strompf  4096 jan  2 15:52 misc/
drwx------ 35 strompf strompf  4096 jan  2 15:52 modules/
drwx------  3 strompf strompf  4096 jan  2 15:52 profiles/
-rwx------  1 strompf strompf  1521 jan  2 17:38 robots.txt*
drwx------  2 strompf strompf  4096 jan  2 15:52 scripts/
drwx------  4 strompf strompf  4096 jan  2 16:20 sites/
drwx------  7 strompf strompf  4096 jan  2 16:20 themes/
drwx------  2 strompf strompf  4096 jan  2 16:20 tmp/
-rwx------  1 strompf strompf 26301 jan  2 18:06 update.php*
-rwx------  1 strompf strompf  4864 jan  2 18:06 UPGRADE.txt*
-rwx------  1 strompf strompf   294 jan  2 18:06 xmlrpc.php*

Rechten goed krijgen

Dit betreft een productie-site, dus simpelweg chmod -R * o+rwx is niet de oplossing (om meer dan één reden). Daarnaast moeten mappen en bestanden andere rechten krijgen. Tijd voor een script, en tijd om 's uit te vogelen wat ook-al-weer de juiste rechten zijn.

Absolute rechten

Met zoiets als chmod o+rwx voeg ik rechten toe, maar haal ik geen rechten weg. Het is beter om niet differentiëel, maar absoluten rechten vast te stellen. Dus bv. chmod 705.

php-bestanden

Om met dat laatste te beginnen: php-bestanden hoeveen geen execute-rechten te hebben. Kijk maar in dit voorbeeld van een admin-menu-installatie:

drwxr-xr-x  6 strompf strompf  4096 dec 31 15:14 ./
drwxr-xr-x 22 strompf strompf  4096 jan  2 14:57 ../
drwxr-xr-x  2 strompf strompf  4096 dec 31 15:14 admin_devel/
-rw-r--r--  1 strompf strompf  2493 dec 31 15:14 admin_menu.admin.js
-rw-r--r--  1 strompf strompf  6177 dec 31 15:14 admin_menu.api.php
-rw-r--r--  1 strompf strompf   890 dec 31 15:14 admin_menu.color.css
-rw-r--r--  1 strompf strompf  5276 dec 31 15:14 admin_menu.css
-rw-r--r--  1 strompf strompf 30911 dec 31 15:14 admin_menu.inc
-rw-r--r--  1 strompf strompf   571 dec 31 15:14 admin_menu.info
-rw-r--r--  1 strompf strompf  3506 dec 31 15:14 admin_menu.install
-rw-r--r--  1 strompf strompf 12267 dec 31 15:14 admin_menu.js
-rw-r--r--  1 strompf strompf  3908 dec 31 15:14 admin_menu.map.inc
-rw-r--r--  1 strompf strompf 31497 dec 31 15:14 admin_menu.module
-rw-r--r--  1 strompf strompf  1260 dec 31 15:14 admin_menu-rtl.css
drwxr-xr-x  2 strompf strompf  4096 dec 31 15:14 admin_menu_toolbar/
-rw-r--r--  1 strompf strompf   174 dec 31 15:14 admin_menu.uid1.css
-rw-r--r--  1 strompf strompf 18273 dec 31 15:14 CHANGELOG.txt
drwxr-xr-x  2 strompf strompf  4096 dec 31 15:14 images/
-rw-r--r--  1 strompf strompf 18092 dec 31 15:14 LICENSE.txt
-rw-r--r--  1 strompf strompf  6564 dec 31 15:14 README.txt
drwxr-xr-x  2 strompf strompf  4096 dec 31 15:14 tests/

En nog een stapje verder: De eigenaar heeft ook geen executive-rechten nodig. Beter dus weglaten, want kraakgevoeligheid.

Speciale geval: Map files

Voor de map files moeten derden recursief schrijfrechten krijgen op map-niveau

Script

Note-to-self: setdrupalrechten.sh

#!/bin/sh

#############
# Variabelen
#############
#
# Gebruik geen ~, want fouten bij gebruik 'sudo'
#
map="/home/gastheer/public/example.com/public"

#
#
#############
# cd
#############
#
# cd $map

####################
# Rechten van mappen 
####################
#
# Eigennaar mag alles (7)
# Group mag nix (0)
# Other: r-x (5)

chmod 705 $(find $map -type d)

####################
# Bestanden 
####################
#
# Eigennaar mag alles maar hoeft niet te kunnen executeren (6)
# Group mag nix (0)
# Other mag alleen lezen r-- (4)
#
# Dit geldt ook voor .htaccess
#
chmod 604 $(find $map -type f)

####################
# Map 'files' 
####################
#
# 'Other' krijgt recursief schrijftoegang op map-niveau
#
chmod 707 $(find $map/sites/default/files -type d)

Voorbeeld van het resultaat:

drwx---r-x 10 root    root     4096 jan  5 15:42 ./
drwxr-xr-x  5 root    root     4096 jan  2 15:43 ../
-rw----r--  1 strompf strompf 47028 jan  2 17:38 CHANGELOG.txt
-rw----r--  1 strompf strompf  1023 jan  2 17:38 COPYRIGHT.txt
-rw----r--  1 strompf strompf   206 jan  2 17:38 cron.php
-rw----r--  1 root    root     4161 jan  5 15:42 .htaccess
drwx---r-x  2 strompf strompf  4096 jan  2 15:52 includes/
-rw----r--  1 strompf strompf   923 jan  2 17:38 index.php
-rw----r--  1 strompf strompf  1269 jan  2 17:38 INSTALL.mysql.txt
-rw----r--  1 strompf strompf  1011 jan  2 17:38 INSTALL.pgsql.txt
-rw----r--  1 strompf strompf 47845 jan  2 17:38 install.php
-rw----r--  1 strompf strompf 15572 jan  2 17:38 INSTALL.txt
-rw----r--  1 strompf strompf 18092 jan  2 17:38 LICENSE.txt
-rw----r--  1 strompf strompf  1867 jan  2 17:38 MAINTAINERS.txt
drwx---r-x  3 strompf strompf  4096 jan  2 15:52 misc/
drwx---r-x 35 strompf strompf  4096 jan  2 15:52 modules/
drwx---r-x  3 strompf strompf  4096 jan  2 15:52 profiles/
-rw----r--  1 strompf strompf  1521 jan  2 17:38 robots.txt
drwx---r-x  2 strompf strompf  4096 jan  2 15:52 scripts/
drwx---r-x  4 strompf strompf  4096 jan  2 16:20 sites/
drwx---r-x  7 strompf strompf  4096 jan  2 16:20 themes/
drwx---r-x  2 strompf strompf  4096 jan  5 15:47 tmp/
-rw----r--  1 strompf strompf 26301 jan  2 18:06 update.php
-rw----r--  1 strompf strompf  4864 jan  2 18:06 UPGRADE.txt
-rw----r--  1 strompf strompf   294 jan  2 18:06 xmlrpc.php

Casus maart 2015: Database was nog niet gemigreerd

PHP-log vermelde geen foutmeldingen. Toen bedacht ik me dat de database nog niet was gemigreerd. Dat hielp!

Casus sep. 2015: Bestandsrechten-probleem

Gelukkig heb ik daar een script voor, en dat werkte:

#!/bin/sh

#############
# Variabelen
#############
#
# Gebruik geen ~, want fouten bij gebruik 'sudo'
#
map="/home/tja/public/example.com/public"

#
#
#############
# cd
#############
#
cd $map

####################
# Rechten van mappen 
####################
#
# Eigennaar mag alles (7)
# Group mag nix (0)
# Other: r-x (5)

chmod 705 $(find $map -type d)

####################
# Bestanden 
####################
#
# Eigennaar mag alles maar hoeft niet te kunnen executeren (6)
# Group mag nix (0)
# Other mag alleen lezen r-- (4)
#
# Dit geldt ook voor .htaccess
#
chmod 604 $(find $map -type f)

####################
# Map 'files' 
####################
#
# 'Other' krijgt schrijftoegang op map-niveau
#
chmod 707 $(find $map/sites/default/files -type d)

Casus sep. 2015: Dankjewel-pagina Übercart-site

  • Oorzaak: Ik had geëxperimenteerd met de SMTP-module. Deze stond wel uit, maar gaf wél een foutmelding
  • Oplossing: Instellingen compleet verwijderen (via Drupal-interface).

Casus sep. 2015: Corrupted menus

Dit betreft een foutmelding die al een tijdje rondvaart. log-entry:

PHP Fatal error:  Unsupported operand types in modules/system/system.module on line 626

Dit lijkt iets met nernaggelde menu's te maken te hebben: [2]. Dit heb ik nu niet gefixet.

Bronnen