I thought my troubles were over but a few hours after I completed my blog troubleshooting for its crawling dashboard, an even worse headache came up. It must have happened around January 27, 2013. On opening moralde.com, this is what appeared on the page.
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, email@example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.2.22 (Unix) mod_ssl/2… Server at moralde.com Port 80
I’ve once seen this notice before on my blog a long time ago, but I remembered it went away and the blog returned to normal after I refreshed it a few minutes after.
So, after seeing that’s it’s not planning on fading away, I accessed my cPanel to do some snooping around.
Cannot Allocate Memory
I found something like these in the ‘Last 300 Error Log Messages’:
[Sun Jan 27 04:17:41 2013] [error] [client ###.###.##.###] (12)Cannot allocate memory: couldn’t create child process: /opt/suphp/sbin/suphp for /home/moraldecom/public_html/index.php, referer: http://www.domain-name.com
[Sun Jan 27 04:16:47 2013] [error] [client ###.###.###.##] (12)Cannot allocate memory: couldn’t create child process: /opt/suphp/sbin/suphp for /home/moraldecom/public_html/index.php
…and so on…
As I still could not make heads or tails of such information, I decided to contact Lunarpages Support. This was my second time to call support. The first time was when my blog got hacked sometime in January 2010 (See What I Did After My Blog Got Hacked). Support was promtly able to help me retrieve my blog back from the hacker’s clutches.
Support replied back saying:
During our routine monitoring of the server where your account is located on, we have found one of your WordPress installations causing severe issues in regards to load on the server, which is also preventing backups from taking place as expected on your entire server. As a result, we were forced to disable your main index.php file, while you can address this issue and resolve it.
And they showed me some SQL query strings which, although I’ve a background in this subject, failed to register in my brain. Support explained that those are queries that are in a locked state and that these are waiting for the first query to finish (which was ‘copying to a temp table’). Because of this the size of the database has ballooned into something really heavy such that all processes are just about to ground to a halt. Well, it finally got grounded the way the cutting-edge tech monstrous minesweeper USS Guardian got grounded somewhere in the reefs in the Philippines. Now, I guess these locked state queries were actually what was causing my WP dashboard to crawl ever so slowly which I blogged about very recently. Lunarpages suggested that the culprit is a specific plugin which I will have to find out and disable immediately. But which plugin?
Which Plugin is the Culprit?
After poring back over the SQL gibberish in the log, I found the table name in the string that goes like “INSERT INTO wp_blc_synch(container_id, container_type, synched)”.
The ‘blc’ part stood out to me and I only knew of one plugin that has such initials in my arsenal: Broken Link Checker!
So, without wasting another breathe I crept inside my dashboard and disabled it without second thought. And for good measure, I also disabled all plugins related to comments inasmuch as the SQL queries also reflected the term ‘comment’ specifically “comment_approved = ‘1’”.
Hereunder thus are the list of plugins I had to disable:
- Broken Link Checker
- WP Captcha Free
- WordPress Thread Comment
Which Plugin Uses the wp_blc_sync Table?
Later, after a little digging into the innards of the Broken Link Checker plugin, I found that indeed it owns the wp_blc_synch table. What I couldn’t understand is how it got to mess up my database when it had been working silently and flawlessly for more than 2 years under the hood of my blog.
[ Update: I found from this webpage that that the broken link checker plugin is one of the plugins among several that they disallow because it overwhelms the server with HTTP requests. ]
Thus, having acquired a certain degree of certainty with regard to the culprit plugin, I re-activated Akismet, CommentLuv, and WP Captcha Free. I didn’t think I need to re-activate WordPress Thread Comment inasmuch as wordpress has this feature natively anyway.
Then, I went back to the cPanel and accessed phpMyAdmin where I deleted the offending bloated table.
With this back-wrenching job done, I reported back to Support about my good deeds and asked them to enable back my main index file. This time however, after not getting a reply after 12 hours, I took the liberty of re-enabling my main index file myself. I just can’t wait to re-activate my blog especially after I received Google’s message about their bot not being able to access my site. You don’t want to keep the big G waiting, do you?
Have you had this harrowing experience before? Getting an ‘Internal Server Error’ glaring back at you is not a funny experience. I’m sure the cause would not always be some wayward plugin. What caused yours?
Warning: Cannot modify header information – headers already sent SOLVED!
I realized just recently that I no longer get that error that has plagued me for a long long time:
Warning: Cannot modify header information – headers already sent by (output started at /home/moraldecom/public_html/wp-includes/post-template.php:##) in /home/moraldecom/public_html/wp-includes/pluggable.php on line ###
Everytime I hit the ‘publish’ button upon completing a new post, or I hit the ‘update’ button after finishing an edit job on a published post, the dashboard page goes blank and just reflect the title of the post and the warning above. Inspite of that, the post gets published anyway. And repeated checks on the post-template.php and pluggable.php files don’t seem to reveal any problem.
Several wordpress updates later, the problem still persisted. The disabling of the broken link checker and the deletion of the database table I mentioned above in this post seemed to have solved the problem.