Date: Thu, 17 Dec 2009 05:30:16 -0500 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: Re-compiling PHP changes server responsiveness Message-ID: <hgd19a$tal$1@ger.gmane.org> References: <4B2851DF.1090107@ozemail.com.au> <4B29E495.7030502@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hgd19a$tal$1>