Hello,
I'm experiencing massive problems with my Apache/PHP webserver. It's running FreeBSD 8.1, i386 branch with GENERIC kernel.
The apache segfaults more or less regularly, however, only "Joomla" is affected. Other PHP applications deployed on the machine can be accessed as normal during such outages. (However, I can't confirm this on a long term scale, as I have no test machine available.)
Symptoms of such a situation are the "white screen of death" when trying to access a Joomla-based website, and in the following message logged:
Running "httpd -V" returns:
The situation can only be cleared by a complete restart of the apache service.
After a thorough search on the web and especially some FreeBSD resources, I was already able to rule out the ZEND multibyte problem. As recommended by several sources, apache was configured to produce a coredump, shown below.
The backtrace confirms, in my opinion, that the problem originates within the PHP module for apache and especially during the creation of new threads in order to handle an incoming request. However, this is just my guess. (I've only got minimal experience with gdb debugging).
This led me to another possible solution, found in the httpd documentation at apache.org, inserting
ServerLimit 512
MaxClients 512
as new directives in httpd.conf within the mpm_prefork complex. However, changing these values (shown are the standard values) only produced more segfaults.
The problems only occured after upgrading to PHP 5.3 from the 5.2 branch.
I have absolutely no further idea what to do. Has anyone else experienced that kind of problem and was able to solve it? Or did I miss anything?
Thank you in advance for any input or idea. If you need any further information, please don't hesitate to ask, I'll provide it as fast as possible.
Regards,
waldmeister
I'm experiencing massive problems with my Apache/PHP webserver. It's running FreeBSD 8.1, i386 branch with GENERIC kernel.
The apache segfaults more or less regularly, however, only "Joomla" is affected. Other PHP applications deployed on the machine can be accessed as normal during such outages. (However, I can't confirm this on a long term scale, as I have no test machine available.)
Symptoms of such a situation are the "white screen of death" when trying to access a Joomla-based website, and in the following message logged:
Code:
Jan 19 18:15:58 SERVER kernel: pid 79045 (httpd), uid 80: exited on signal 11
Code:
Server version: Apache/2.2.17 (FreeBSD)
Server built: Oct 22 2010 20:50:07
Server's Module Magic Number: 20051115:25
Server loaded: APR 1.4.2, APR-Util 1.3.10
Compiled using: APR 1.4.2, APR-Util 1.3.10
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_FLOCK_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/usr/local"
-D SUEXEC_BIN="/usr/local/bin/suexec"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="etc/apache22/mime.types"
-D SERVER_CONFIG_FILE="etc/apache22/httpd.conf"After a thorough search on the web and especially some FreeBSD resources, I was already able to rule out the ZEND multibyte problem. As recommended by several sources, apache was configured to produce a coredump, shown below.
Code:
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
{...}
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x28a57eb9 in do_bind_function ()
from /usr/local/libexec/apache22/libphp5.so
[New Thread 2c1abf40 (LWP 100202)]
[New Thread 28501140 (LWP 100230)]
(gdb) bt
#0 0x28a57eb9 in do_bind_function ()
from /usr/local/libexec/apache22/libphp5.so
#1 0x28a94a04 in ZEND_DECLARE_FUNCTION_SPEC_HANDLER ()
from /usr/local/libexec/apache22/libphp5.so
#2 0x28a958a9 in execute () from /usr/local/libexec/apache22/libphp5.so
#3 0x28a71734 in zend_execute_scripts ()
from /usr/local/libexec/apache22/libphp5.so
#4 0x28a1f1c9 in php_execute_script ()
from /usr/local/libexec/apache22/libphp5.so
#5 0x28af414e in php_handler () from /usr/local/libexec/apache22/libphp5.so
#6 0x08076b19 in ap_run_handler (r=0x2c226058) at config.c:157
#7 0x08079dee in ap_invoke_handler (r=0x2c226058) at config.c:376
#8 0x08084eb0 in ap_process_request (r=0x2c226058) at http_request.c:282
#9 0x0808201b in ap_process_http_connection (c=0x29cf41f0) at http_core.c:190
#10 0x0807de09 in ap_run_process_connection (c=0x29cf41f0) at connection.c:43
#11 0x08089791 in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at prefork.c:662
#12 0x08089a77 in make_child (s=0x28510f10, slot=0) at prefork.c:763
#13 0x0808a427 in ap_mpm_run (_pconf=0x2850f018, plog=0x2853d018, s=0x28510f10)
at prefork.c:898
#14 0x08064195 in main (argc=676384792, argv=0x29cf2018) at main.c:739The backtrace confirms, in my opinion, that the problem originates within the PHP module for apache and especially during the creation of new threads in order to handle an incoming request. However, this is just my guess. (I've only got minimal experience with gdb debugging).
This led me to another possible solution, found in the httpd documentation at apache.org, inserting
ServerLimit 512
MaxClients 512
as new directives in httpd.conf within the mpm_prefork complex. However, changing these values (shown are the standard values) only produced more segfaults.
The problems only occured after upgrading to PHP 5.3 from the 5.2 branch.
I have absolutely no further idea what to do. Has anyone else experienced that kind of problem and was able to solve it? Or did I miss anything?
Thank you in advance for any input or idea. If you need any further information, please don't hesitate to ask, I'll provide it as fast as possible.
Regards,
waldmeister
: