Intermittent 404 errors

[zensurf]

I've been trying to resolve this issue for days. Our installation of OCS at a previous host would return 404's periodically, seemingly for no reason. Clicking the link again would get the page back. I suspected this was a timeout or memory issue, so we moved the install to a new host (and for other reasons). The new host has more memory for PHP (90MB) and a 60 second socket timeout (which I believe is standard). The 404's persist, and seemingly at a greater rate (sometimes 1 in 5 clicks, sometimes every other click).

What seems to be happening is that OCS will return a URL without the "index.php", which causes the script to fail. Even if the link has index.php visible in the URL, intermittently it will switch the URL removing it.

E.g. if you go to our site:
http://www.visibleevidence.org/18/

and alternately click, say, "Presentations" and "Registration" in the right hand navigation menu, you will eventually get a 404. Actually, you may get a 404 simply visiting the site for the first time. What happens is, you'll be directed to:

http://www.visibleevidence.org/18/ve18/ ... gistration

when you should have been directed to:

http://www.visibleevidence.org/18/index ... gistration

We are running WordPress and MyBB on the same server flawlessly. I have also tested the install eliminating WP .htaccess redirects, in case that was the problem. No luck.

Here are the server specs:

PHP Version 5.2.15
MySQL 5.0.51a
OCS 2.3.3-1 (original clean install, no patches)
Host: Dreamhost.com, Apache/Linux (not sure the exact version, as the block the server header.

404's are returned at about the same speed as an actual page, so it doesn't seem to be a timeout, and memory really should not be an issue with a 90MB limit.

Thanks in advance!

[zensurf]

It seems like Dreamhost is killing the process because it's taking up too many resources. Is this something common to the current version of OCS? I haven't confirmed it with them yet, but the intermittent internal server error, which was being trapped by WordPress and converted to a 404, was reported in the logs as "Premature end of script headers: index.php". This is pretty typical of a killed script.

Simply sitting on one page and reloading it a few times will give me the error anywhere from 20% to 30% of the time.

Have other users had problems with Dreamhost in the past? I found people with issues running Drupal, which is supposed to be a resource hog, but those were resolved.

[jmacgreg]

Hi zensurf,

I run a number of OxS test installs on Dreamhost, without problems. (None of them are high-traffic whatsoever, of course, but I've never seen a 404 as you've described.) I'll ask a developer to get back to you on this, but in the meantime, could you let us know if you've made any modifications to the code, and what your disable_path_info is set to in your config.inc.php file?

Cheers,
James

[zensurf]

Hi James,

Thanks for the quick response. My disable_path_info = Off. I didn't think that could be the problem since the errors weren't constant, as though a variable wasn't available, but only intermittent. Maybe I don't understand how it was used.

The 404's seemed to increase when we had more users, and at peak periods doing things like reviewing submissions, which would take up more resources. In debug mode, though, it didn't seem to indicated an overly high use of memory, but maybe multiple instances at once was the problem and I had no way to track that.

I found out that Dreamhost runs PHP as a CGI, not an Apache module, so maybe this is part of the problem?

At any rate, I zipped up the folder and dumped the SQL database to a file and moved both to a new host (Bluehost) and it seems to be running fine now.

[jmacgreg]

Hi zensurf,

Hrm, that's all very strange indeed. Just out of curiosity, did you enable FastCGI on your Dreamhost account? (I think that's an option for every site you host -- you can choose between "regular old" and FastCGI under Domains -> Manage Domains in the DH panel.) IIRC we actually prefer using FastCGI on our own SFU servers for the journals we host, for security and speed reasons.

Anyway -- I hope Bluehost works out better, and let us know if you run into anything else!

Cheers,
James