Re: Re-compiling PHP changes server responsiveness
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_modulelibexec/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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Re-compiling PHP changes server responsiveness
Matthew Seaman wrote: Ian Fitzgerald wrote: Recently upgraded (fresh install) FBSD 8, including MySql, Apache22, phpMyAdmin, KDE4 Gnome2.26 from DVD iso. Running ok as test server, but unusual error from added, complex CMS prompted me to re-install PHP5 and PHP5-extensions as pkg_add -r (using ports files from iso), then with no success, compiling them (using ports files from iso), with slightly different make config. Now server does not respond, either to 'localhost' request on its browser, or specific address request from another machine on local network. I assume re-compiling PHP would not clobber hosts or resolv.conf (they look ok). 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. Tried refreshing ports (inital re-compile attempt failed with make complaining that postgres-client had been marked invalid - when will someone fixit?), and re-compiling apache22 = no change. ps -auxc: no httpd. FF3 under Gnome on the machine fetches external pages, of course (using router DNS). 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. Cheers, Matthew Thank you . That gets me off to a good start. I guess the solution for the maintainers is simple: a script which automates every combination of module load to test for error-prone sequences or combinations. These could then be tested for and a warning notice issued at config time, or after compilation, preferably. It would also provide a definitive answer to the question of whether the sequence/combination is a contributing factor in the first place, or whether some other factor is a pre-condition. -- ianf http://www.metapixeldesigns.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re-compiling PHP changes server responsiveness
Recently upgraded (fresh install) FBSD 8, including MySql, Apache22, phpMyAdmin, KDE4 Gnome2.26 from DVD iso. Running ok as test server, but unusual error from added, complex CMS prompted me to re-install PHP5 and PHP5-extensions as pkg_add -r (using ports files from iso), then with no success, compiling them (using ports files from iso), with slightly different make config. Now server does not respond, either to 'localhost' request on its browser, or specific address request from another machine on local network. I assume re-compiling PHP would not clobber hosts or resolv.conf (they look ok). 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. Tried refreshing ports (inital re-compile attempt failed with make complaining that postgres-client had been marked invalid - when will someone fixit?), and re-compiling apache22 = no change. ps -auxc: no httpd. FF3 under Gnome on the machine fetches external pages, of course (using router DNS). What else should I look at? -- ianf http://www.metapixeldesigns.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Re-compiling PHP changes server responsiveness
Ian Fitzgerald wrote: Recently upgraded (fresh install) FBSD 8, including MySql, Apache22, phpMyAdmin, KDE4 Gnome2.26 from DVD iso. Running ok as test server, but unusual error from added, complex CMS prompted me to re-install PHP5 and PHP5-extensions as pkg_add -r (using ports files from iso), then with no success, compiling them (using ports files from iso), with slightly different make config. Now server does not respond, either to 'localhost' request on its browser, or specific address request from another machine on local network. I assume re-compiling PHP would not clobber hosts or resolv.conf (they look ok). 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. Tried refreshing ports (inital re-compile attempt failed with make complaining that postgres-client had been marked invalid - when will someone fixit?), and re-compiling apache22 = no change. ps -auxc: no httpd. FF3 under Gnome on the machine fetches external pages, of course (using router DNS). 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. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
