trouble white screen of death

How to recover from WSOD, or a Blank Screen

... when I republish an entry

Your rebuild is likely timing out.

Step One: Identifying The Expensive Template

• If the WSOD happens before the entry shows "Republishing <entry title>....", Check to see if there are any multiblog triggers that affect this blog. You'll need to focus on that blog in your template debugging if the current blog rebuilds the multiblog-based blog.

  mysql> select * from mt_plugindata where plugindata_plugin='Multiblog';
  

• You have a few options after that.

  • Identify which index templates are being republished on entry save. It may help to turn each on to publish either manually or static as you're debugging just so you can rule out which templates rebuild in a timely manner.
  • Use the BuildTracer plugin to find out how long each template is building. The downfall of this tool is that it is also susceptible to WSODs. Once the template is installed, go to Manage -> FileInfo. Indexes are shown by default; entries are in the right sidebar.
  • Turn on Performance Logging.
    • Create a directory on the server where the daily log files will be created. Make sure Melody can write new files to the dir. (we'll use /var/log/mt/ as the example here.)
    • In the config.cgi file, add the following: DebugMode 8 PerformanceLogging 1 PerformanceLoggingPath /var/log/mt/ PerformanceLoggingThreshold 1.0
    • Read the full documentation for performance logging
    • The PerformanceLoggingThreshold is in seconds, so the above example will print to the daily file generated in /var/log/mt any templates that take longer than 1.0 seconds to rebuild.
    • prompt> tail -f /var/log/mt/<todaysfile>.log

Step Two: Caching the Expensive Template

• Do your best to identify the "expensive", or time-costly, code in your template. BuildTracer is your best start, but you may be able to tell just by looking. Costly tags include:
  • Recommend counts
  • mt:entries loops with categories
  • anything across all blogs
• Whether or not you can find it, cache the template's contents for now.
  • Turn on Template Module caching. Settings -> Publishing.
  • If the template wasn't already a module, create one and copy the original contents into the new module, named costly_template or something. Then be sure to <mt:include module="costly_template"> in the original template.
  • Cache the template module by expanding the options at the bottom. The window of time is your choice, as is the reason for expiration, but make it higher than 10 minutes for the sake of debugging. You can always decrease it later.
  • Go back to the original condition that caused the WSOD (likely saving an entry) and try again. Repeat Steps One and Two until all costly code has been identified and cached.

...when I view Manage -> Assets

• This can happen when:
  • an image you've uploaded is corrupt
  • an image you've uploaded is a different type than its extension (ex: uploading a PhotoShop file that ends in .jpg)
  • a file you've uploaded can't be handled by your image library (ex: your ImageMagick installation can't handle .png-formatted files but you uploaded one anyway
• It's happening because the underlying image library (like ImageMagick or NetPBM or something) is trying to create thumbnails on files that MT classifies as 'images' (based on file extension ONLY as of MT 4.23). The library dies at the system level and doesn't give any indication to MT as to why it died; just a WSOD.

How to pinpoint your Bad Asset

You'll need Melody access and database access. This is the strategy:

1. Find the bad asset(s).

• Go to Manage -> Assets and find an offset of assets that isolate the bad one(s).
  • You should see a WSOD here.
  • Add '&offset=25' in the url. This will ignore the 25 most recent assets uploaded to this blog.
    • If you still see a WSOD, you either have more than one corrupt asset or or a bad Image Magick installation. Can you view the assets for any other blogs (not system level)? This is likely not the result of one singular file and won't be straightforward to track down.
    • If you don't see a WSOD with the older assets (offset=25), then you know that some asset in the most recent 25 is our target. Decrease the offset value in the URL until you have a decent-sized sampling set (say 5 for arguments sake).

2. Look up the asset's information in the database and find which individual ones make WSODs (given your blog_id=m, offset=n)

• select asset_id, asset_class, asset_url from mt_asset where asset_blog_id=m order by asset_created_on desc limit n;
• View each MT::Asset object through the Edit Asset screen in Melody. The parameters will be like this: index.cgi?__mode=view&_type=asset&blog_id=10&id=8099 , so change the id parameter every time. The Edit Assets that do NOT lead to WSODs are safe. Pinpoint the id's that lead to WSODs.

3. Either (1) remove the mt_asset rows that are bad, or upload another file of the same name (to overwrite the bad one) that is not corrupt/of the wrong type.

• If you remove the mt_asset row, you won't be removing the physical file from the server, but it will take the offending object out of the Manage Assets listing. Uploading the same file to overwrite the offending one is the best approach, since the problem lies with the physical file itself. But be sure that you know why this image is broken before you upload another in its place. If its type is actually a Photoshop file but you named it with a .jpg, use some other program to actually convert the file to be in the jpg format. If your Image Magick doesn't allow pngs, don't upload them---even when they end in .jpg, ImageMagick can still tell how the file is formatted despite its extension. Firefox is pretty good at determining file type (in the top Title bar) based on a url, although curl is the superior tool.

 

Questions, comments, can't find something? Let us know at our community outpost on Get Satisfaction.

Credits

• Author: Six Apart Ltd.
• Edited by: Violet Bliss Dietz