Help - Search - Members - Calendar
Full Version: Frustrating Intermittent Apache/PHP Problem
The Planet Forums > System Administration > Web Hosting
HockeyGirl
Hi All,

I am really hoping that someone will be able to give me some inspiration on a problem I've been trying to resolve. In the last week I migrated a website running on an old RHE EV1 server to a Centos 5 The Planet server. It's a straightforward Apache/MySQL/PHP site.

The transfer was pretty painless, but I gradually became aware that about 1% of PHP page requests were being returned with the source of the PHP page, rather than the processed output. I confirmed this by running a bash script, repeatedly calling WGET from a remote machine -- 99% of the time the correct output would be returned, but 1% of the time the PHP source would be returned.

There are no error messages in the source PHP returned, nor in the Apache error logs (even on 'debug' LogLevel). The Apache logs just show a normal entry for those 1% of failures (except the size is different).

The old EV1 machine had been restored (to RHE5), in preparation for cancellation. Instead I uploaded a copy of the PHP pages, and remotely connected them to the MySQL database on the new Centos 5 server. The same tests on the RHE5 server never replicate the fault on the Centos 5 server, even after ten thousand accesses (by script).

I am at a loss to diagnose this fault, given that it is entirely intermittent, and occurs with no error message at all. Both machine are fully up to date (through yum).

I was hoping that some kind member might give me a little inspiration of a direction to head to explore/diagnose this fault.

Thanks in advance for ANY suggestions on this.

Sarah
Tomy Durden
Sarah,

Does /var/log/messages show any segfaults for PHP? Also, can I have a technician replace the memory in your server, just in case?
HockeyGirl
It seems, after very tedious investigation, that we've found a bug in PHP. In certain circumstances the "php_flag engine off" statement can leak from the virtual host in which it was used and impact a another virtual host. How often this occurs seems to depend on various factors influencing server load. For us it was occurring between 0.01% and 1% of the time.

Sarah
thedude
I assume this was with PHP5?

Were you able to fix this? If so, how?

Be good to know in case any of us ever run into this problem.
HockeyGirl
QUOTE (thedude @ Jan 27 2008, 10:26 PM) *
I assume this was with PHP5?

Were you able to fix this? If so, how?

Be good to know in case any of us ever run into this problem.

Yes we're on PHP5, but PHP4 is affected. Now we know what the problem is, we did find PHP.NET bug reports going back to 2003 on this issue.

http://bugs.php.net/bug.php?id=25753

Unfortunately the PHP.NET incorrectly mark some pertinent bug reports as "BOGUS". What they mean is that they are entirely valid bug reports, but just specific cases of a wider PHP bug (and as such duplicates). This misrepresentation of status is confusing.

http://bugs.php.net/bug.php?id=25743

The PHP team have still not been able to fix this problem for 5 years -- which is quite amazing. As far as I can determine, this is a bug introduced concurrent with Apache 2, and probably related to faulty multi-threading code in PHP.

The official answer appears to be that if you use "php_flag engine off", or infact ANY php_flag statement in a virtual host, then you need to include it in all virtual hosts to avoid this problem.

We were able to remove the "php_flag engine off" statement entirely -- it was primarily a safety mechanism that was mostly redundant now. Our tests suggested, however, that php_flag statements probably don't leak if put inside <directory></directory>statements inside of the relevant virtual host. If it is suitable for your situation, you can alternatively put the php_flag in an .htaccess file.

See also the note by outofnet at http://ca.php.net/apache

Sarah
thedude
Thanks for the info Sarah...good stuff.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.