White Screen of Death (Drupal)
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:
- Debuggen
- .htaccess (Drupal) - Weergave van geavanceerde foutmeldingen
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
- http://stackoverflow.com/questions/6025828/debugging-drupals-white-screen-of-death
- https://drupal.org/node/158043 - Blank pages or "white screen of death" (WSOD)
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).
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.