ARGH!

After installing a few sundry PHP applications and databases, I found that I was regularly (and easily) producing 500 errors.

Support can be very frustrating… Resolution after the break…

According to the World Wide Web Consortium, a 500 error is:

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

So, I get on the phone with GoDaddy support when I can no longer access ANY web services due to the error, and start performing like a circus dog jumping through hoops.

I understand and sympathize with support personnel and accept that I have to follow the steps they detail me when I call so that they can properly resolve or escalate my issue.

After I explained to them that the 500 error was a SERVER / HOST error, they had me pinging and checking my traceroute to my server to verify connectivity.  They kept making sure my local network was fit.

I explained that I tested this on THREE different browsers (Chrome, Firefox and Internet Explorer) and on TWO different computers (one wired and one wireless).  I also told them that this could not be caused by anything on my end and I still could get to the content via FTP and their web hosting interface.

After being hit on the head with the dreaded “I can’t seem to reproduce it here” stuff, I was informed my issue would be escalated.  While I was waiting on hold, I managed to locate host side error logs that I had recently enabled (just in case of stuff like this) and asked if they needed them.  I was told that they probably wouldn’t need them (B to the OGGLE).

I get an e-mail back asking if I can SCREENSHOT THE 500 errors and send that to them.

wat?

Ok, this is getting silly, and I could probably resolve this much faster by speaking with my mouth over the electronic cellular conveyance to another (hopefully) more experienced individual.

I called back, and found that I could only talk to the higher up support personnel by responding to the e-mail they sent me.  GAH!

I e-mailed back the DIRECTORY the log is stored in ON THEIR SERVERS along with a copy of the LOG FILE ITSELF to the e-mail.

The errors SPECIFICALLY were:

[Tue Dec 08 12:25:17 2009] [error] [client 68.x.x.x] FastCGI: comm with (dynamic) server "/var/chroot/home/content/.../html-x-httpd-php5" aborted: (first read) idle timeout (60 sec)
[Tue Dec 08 12:25:17 2009] [error] [client 68.x.x.x] FastCGI: incomplete headers (0 bytes) received from server "/var/chroot/home/content/.../html-x-httpd-php5"

I get a response this morning (FINALLY) telling me the following:

Dear Sir/Madam,

Thank you for contacting Hosting Support.

I would suggest changing the php to not use fastcgi. You can do this by going into the hosting control center and clicking settings then from the drop down menu select file extensions. Once the page load click edit next to .php on list and then from the drop down box choose PHP 5.x. This should resolve the issue and prevent it from occurring again.

Please contact us if you have any further issues.

Ahh… FastCGI… Now we’re getting somewhere.  I remember seeing that in the Extensions section of their GUI setup.   I also remember seeing it referenced in the different plans you can purchase.  Being the cheap bastard that I am, I went for the Economy package.  It seems though, that it does not EXPLICITLY say whether or not FastCGI is part of your service in any of the plans, unless you plan on using PERL scripting or Ruby on Rails.  I am using neither, but it is STILL enabled by default.

Biting the bullet, I turned the association with PHP files to just normal PHP 5.x an voila, no more errors AND general page response time seems considerably faster.

I’ve seen other people with the same problem, and I think it has to do with the Shared hosting more than the economy plan.

Caveat Emptor (even though there was no way to caveat).

** EDIT: The errors on my hosting have come back, and it is SLOW as molasses.  The fix I listed above WILL NOT CURRENTLY WORK.  The options for changing the extension types for PHP have been removed from the management interface, so I am assuming mine have defaulted back to the FAST-CGI stuff;  I’ll try and find a fix for this soon.

Be Sociable, Share!

• 
•