Re-compiling PHP changes server responsiveness

[Michael Powell]

Matthew Seaman wrote:

[snip] 
>> I get: "[warn] (2)No such file or directory: Failed to enable the
>> 'httpready' Accept Filter, and no new errors in
>> /var/log/httpd-error.log" four times
>> 
>> Tried adding accf_http="YES" to /boot/loader.conf, and re-booting of
>> course.
> 
> This is just a warning message and doesn't stop apache working or not. 
> Enabling accf_http should give you a bit of a performance boost under
> heavy load and help you withstand certain types of DoS attack, but it's
> not required.
>

I found I needed both accf_data_load="YES" and accf_http_load="YES", but I 
am also running SSL too. I've also noticed that I tend to not receive this 
error when Apache starts after a fresh system boot. Have never tried to 
examine it further as I don't reboot or restart Apache very often. It just 
seemed happier when I added the http_load into the mix and only spews the 
error at non-reboot restarts.
 
[snip] 
>> What else should I look at?
>> 
> 
> Try restarting httpd from the command line: /usr/local/etc/rc.d/apache22
> restart
> 
> This will run a configtest and then try and start up apache.  Then check
> that apache is still running: /usr/local/etc/rc.d/apache22 status
> 
> If apache has mysteriously disappeared and there are no messages in log
> files, then it means apache crashed during the startup process soon after
> daemonising. That's pretty diagnostic for loading a dynamic module that
> disagrees with it.
> 
> At a guess, and given that you've reinstalled all your php modules, I
> think you
> may be being hit by the php module load order problem.  In that case,
> running
> php from the command line will probably also segv on you.  This is
> something that has had quite a lot of attention on this list, but there
> isn't a really good solution yet, other than manually reordering the
> entries in /usr/local/etc/php/extensions.ini
> 
> Also, if you're running eAccelerator, make sure you recompile it at the
> same time you upgrade the main lang/php5 port: eAccelerator will cause
> Apache to crash if you try and run it against a different version of PHP
> than it was originally compiled for.
> 

The same would apply whether it was xcache or the Zendoptimizer.

The way to pin the problem down is to rename extensions.ini temporarily to 
extensions.ini.bak and comment out the 

#LoadModule php5_module        libexec/apache22/libphp5.so line temporarily.

Start/restart Apache and if it works OK with serving static content it 
confirms the problem is PHP. Then add the Loadmodule line again in 
httpd.conf and restart. If it restarts with no errors and again serves 
static pages fine the PHP module itself is OK. Trying to run something like 
a CMS will still be error prone as the various modules it needs aren't being 
loaded and found, as the extensions.ini file is still renamed.

Note that if Apache is happy with mod_php while extensions.ini is still 
renamed it also confirms no major flaw in the php.ini file.

If Apache runs fine with the mod_php module then the trouble is in the 
extensions. Rename the extensions.ini back to it's original state. There is 
a script that may be run to realize a close approximation of the extension 
loading order problem: fixphpextorder.sh which can be found here: 

http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround

That is a stab at the reordering problem, but in my case was not enough to 
completely solve my problem. I also had to comment out extension=mhash.so 
with a ";". This was arrived at by commenting out line by line one at a time 
until I hit the one causing the breakage. This particular extension has been 
problematic for me for some time now. Some upgrades it works and for some it 
is broken. Remember that each change made requires an apachectl restart.

-Mike