Repeated 500 Errors - web8 : Anyone else?

Customer Support Server/Network Issues
1

Is anyone else getting repeated 500 errors like this?

Error 500: Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.

The problem is on the server side, not with your browser or the address. Most probably, a certain service (e.g., Tomcat engine) is down. Please contact your webmaster.

This has been a recurring error on a web8 site. I moved the site to a new account, also on web8 and continue to have this problem. It has been happening frequently enough that my client has seen it three times since the site launched yesterday. It was also seen while the site was in development on the earlier account.

2

i have a client w/ a site on web8 who is seeing this very frequently and is getting tired of it. right now, their site is basically unresponsive because of it. jodohost, any update on this?

3

This issue is totally out of hand and is destroying client trust on web7 and web8. The new web9 server currently fails to allow proper operation of a WordPress based sites as well.

4

Yes same here for 2 customers, for one site the following showed repeatedly in the error log

No such file or directory: FastCGI: failed to connect to (dynamic) server “/hsphere/shared/php5/bin/php”: something is seriously wrong, any chance the socket/named_pipe directory was removed?, see the FastCgiIpcDir directive

These entries seemed to coincide with the times my customer was getting the 500 status errors. Tech support said that they had made some changes that hopefully will solve the issue/s I reported

5

I get that same error frequently. It alternates with this one: FastCGI: incomplete headers (0 bytes) received from server “/hsphere/shared/php5/bin/php”

And yes, those are the times the 500 errors are happening. I’ve been pushing on this for 3 months with no improvement.

The new web9 server is also throwing errors and is unusable for basic WordPress functionality at this time.

6

Yep, I’ve seen that entry in the logs numerous times as well although in my case it turns up on joomla installations. I did see a non jodo forum post about earlier apache versions and fast cgi being the culprit and the newer apache version not having the issue. Unfortunately I don’t have the forum post URL or the apache versions handy but googling the log entry I posted was what turned up that particular answer.

7

Tanmaya has found the issue related to web9, it is totally different than others. He has been helping one of you I believe here tonight.

Basically it was remote loaded content that was at fault, nothing else.

8

Stephen - the block on the external RSS feed seems to be resolved this morning at about 10:15 Central when the feed finally loaded. It took around 4 days for that to be remedied.

This has not been the only issue on this new server.

It’s logging errors every minute or so on the dev site I have there.

9

Make sure the errors are pasted to ticket, I can’t do anything about this but the more info there the better.

The server doesn’t have much on it and is also having a lot of resources, so the issue is not resources or anything like that, I don’t know enough on this to check it.

10

So, I moved a critical client site from web8 to web9 in an attempt to deal with this 500 error issue, only to find more of the same on web9, but with the added feature of some new, exciting 400 errors as well (I’ve got a ticket in on this, but expect I’ll get the usual “problem is solved, please check” and be none the wiser as to what was wrong and what was done).

As as I can tell from some quality time spent with teh google, it may have something to do with mod_security being poorly implemented on the server. As it is, the rules are certainly blocking several legitimate crawler requests on my site, and is causing multiple misfires on the back end admin side of things in joomla – I would imagine the same to be the case in WordPress, Drupal and other CMS’es that rely on URL encoded query string stuff to process updates.

Several comments on there mention the fact that mod_sec also causes significant server load – which might explain some of the timeout-flavored 500 errors? (I defer to our virtual overlords on this one; I pay them to be the competent server admins that I’m not).

This is, however, severely straining my relationship with a couple of clients, and my new years’ resolution was to not let that kind of stuff slide. So: any chance we could ask the admins to pls take a look at the mod_sec settings and see if they can be relaxed a bit or tweaked so they don’t get in the way of our sites’ running the way they’re supposed to?

11

I’ve said this many times in the past. Please feel free to ask what was done. We have some new techs in for these tasks, and a few tend forget to give basic info on what was done, and will be reminded.

Please share with us, what was blocked?
As for as I know it only notifies that there was a bot scan.

Some of our custom exclusions were missing on web9, and have been put there now. Please update the ticket, or let us know here if mod_security continues to block basic operations of the software.

mod_security has indeed contributed to the issue, but is not the root cause. We prefer server that is less prone to script kiddies, and this is why mod_security is there. I’m not sure there are many host who would prefer to offer this level of security customization on shared hosting at expense of server and manpower resources. On this note, mod_security may not be there in future, as now we have users isolated to their own users privileges with fastcgi, and its user’s responsibility to maintain their site permissions, and keep code secure.

12

tanmaya,

thx for your follow up; I’m sorry if I came across as unhappy w/ the techs… just frustrated w/ the fact that my client was asking for answers I couldn’t give.

I’ve updated my ticket w/ some follow-up, and wanted to confirm that all it takes is to ask the techs for some additional info in order for it to be provided.

When you write:

now we have users isolated to their own users privileges with fastcgi, and its user’s responsibility to maintain their site permissions, and keep code secure.

I’m curious if you can give us some additional info on setting up permissions w/ fastcgi on the joomla shared servers – my error log still shows a number of fastcgi related errors, like:

FastCGI: comm with (dynamic) server "/hsphere/shared/php5/bin/php" aborted: (first read) idle timeout (30 sec), FastCGI: incomplete headers (0 bytes) received from server

And I frankly have no idea how to troubleshoot this, but it sounds like I should find out…