Subscribe to
NSLog(); Header Image

MT 3.2 Final – 500 Error Bites

This blog is now running MovableType 3.2. It - so far - is working beautifully.

The Sand Trap is also "running" MovableType 3.2. It isn't working beautifully at all. In fact, it's not even really working.

Since installing MT 3.2 on The Sand Trap, I've had HTTP 500 errors left and right when I rebuild anything (by deleting a comment, re-saving an article, "Rebuild Site," etc.). Initially, I had 500 errors just logging in to the site, but those seem to have gone away. The errors when rebuilding persist hours later.

Permissions (755) are correct. I don't have CPanel (one of the former causes of 500 errors). I didn't have issues with 3.16. I have no idea what the problem could be, and turning on Debug mode hasn't shown me any errors. More information appears below, as I discover it.

I've sent an email to support. They've yet to respond. I'll update when they finally get around to it.

  • The error occurs any time I re-publish an article, it seems, except when I post a comment. I get no 500 error then. However, I do get errors when I attempt to rebuild the site manually ("Rebuild Site") or when I rebuild an entry ("Save"). I also get the error when I delete a comment which forces a page to rebuild.
  • All that appears in the error_log is this: [Fri Aug 26 14:10:21 2005] [error] [client] Premature end of script headers: mt.cgi, referer: Despite the fact that Six Apart reps say that "With every 500 error, there are at least two messages in the server error log: the "premature end of script headers" one and the actual error message that caused the "premature end of script headers" error," this is most certainly not the case. Only one message is logged.
  • I'm not using CPanel. DBD::mysql is version 2.1021. DBI is version 1.32. The server is running Linux. The Web server itself is apache/2.0.46.
  • Despite the 500 error, the page is rebuilt successfully.
  • Publishing a new entry results in an error as well.
  • My plugins are all stock on The Sand Trap except RandomLine. Disabling it has no effect. Disabling all plugins has no effect - I still get 500 errors.
  • I re-uploaded (again) everything explicitly in ASCII mode. Nada - no help.
  • Uploading everything to a different location does not work either.
  • TrackBacks aren't sent when this error occurs, despite the fact that the actual publishing seems to occur.
  • My settings are, for the most part, exactly the same as on NSLog();. When they differ, setting them to be exactly the same does not resolve the issue.
  • When I set an article to publish in the future and then manually run the periodic tasks via SSH, I get six lines of No handler exists for tag _TRANS at lib/MT/ line 170.
  • For some reason, the Settings tab in NSLog(); has an "IP Banning" tab while the Settings area on The Sand Trap does not. The "Commenters" list on The Sand Trap is also empty, but quite full (162 full) on NSLog();.
  • Turning off background tasks has no effect.
  • I can create a new blog ( that does not experience these problems, even if they use the same templates. I haven't mirrored every setting, of course, but I did copy and paste the templates over.

I would like to update things like the comment form in my individual entry template, but I'm finding it nearly impossible to do so due to the fact that rebuilding anything generates this error, even if the entry is rebuilt in the end.

13 Responses to "MT 3.2 Final – 500 Error Bites"

  1. I posted a question in the forums here too. My official support request is "awaiting staff response" currently.

  2. Still no response from 6A. I ran another article as a "Scheduled" article and manually ran the periodic tasks CLI app and got the same thing, "No handler exists for tag _TRANS at lib/MT/ line 170."

  3. Six Apart's "Sarah," thus far, is stumped. She had me do some routine things, then create another blog, etc. Still no go. I gave her access to the site and hope to see a resolution soon.

    Personally, I'd like to find a way to re-run the entire upgrade script. Setting the database version back a notch does not do it - it updates the version number and that's all.

  4. Six Apart has not responded to my support request - despite a LOT of additional information (including full access information to the server, the MT login, and FTP) - since Friday. I hope that they don't take the weekends off there at 6A, even if they just released a new version, because the Internet and blogging don't know what a "weekend" is.

    This is the first time I've ever needed support - support I paid for - and thus far, I'm not really getting it. I'm very disappointed.

  5. Shelley has responded. Thanks. And Brad (Choate) has written to me as well to help solve the problem. Good stuff. 5pm (west coast) on a Sunday to boot.

    I didn't expect the problem to be resolved this weekend, but two days without someone saying "hey, we're still working on your problem" was a little odd. I'm glad they're still aware that the problem isn't resolved and are working on it.

  6. Problem somewhat solved. Brad believes he's found the cause of the problem: a low Apache Timeout value. It's 5. Default, says Brad, is 300.

    More information in the TrackBack.

  7. Brad Choate (yes, there's only one) spent some time with my "Error 500s with MovableType 3.2" issue yesterday and believes he's found the source of the problem: a low Apache Timeout value. Default used to be 1200, but that was...

  8. Hi erik,

    I have also encountered the " No handler exists for tag Archive at lib/MT/ line 170." message.

    Did Brad sort that problem out for you too with his timeout thing.

    Any help would be great.


  9. It's everything but easy to upgrade Movabletype 3.2

    Despite Six Aparts warm promises of the easiest upgrade ever, upgrading Movabletype to version 3.2 is everything but painless. To be frank, it's a full featured pain in the ass. I'm not sure wether they do this by purpose or...

  10. Any Luck Yet ?

    I'm having the same 500-error problems ... and would like to rebuild my individual archive ....

  11. [quote comment="21323"]Any Luck Yet ?[/quote]
    Look in the comments above. Or click this to see if you have the same cause of the problem as I had (a low Apache timeout value).

  12. Thanks! I'll let my hostingservice check the apache timeout value :-).

    I'll let you know if it works!

  13. Apache Timeout value IS the problem !