ID: 26494
Comment by: dimitrij at schlund dot de
Reported By: hexer at studentcenter dot org
Status: No Feedback
Bug Type: Apache related
Operating System: Linux
PHP Version: 4.3.4
New Comment:
Hi,
we have same problem too. It is very critical if you use LAMP. This
kills any MySQL Server if the php script has a connection to this
server and stocks.
Dimitrij
Previous Comments:
------------------------------------------------------------------------
[2003-12-07 12:00:08] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
------------------------------------------------------------------------
[2003-12-02 21:52:43] [EMAIL PROTECTED]
I am having some difficulty replacating the problem and have not been
able to get it to happen YET. Meanwhile could you please see if the
problem occurs with PHP is compiled with mysql support?
------------------------------------------------------------------------
[2003-12-02 15:06:49] hexer at studentcenter dot org
it seems that somewhere along the line, SIG_ALRM handler gets rerouted
or disabled in one of the php extensions (I'm highly suspecting mysql)
since apache's timeout relies on SIG_ALRM anything within php that
disables it will break the timeout mechanism.
The stuck processes abort normally when calling the handler directly
from GDB, however when receiving SIG_ALRM nothing happens.
the following is the config string for php
./configure --with-mysql \
--with-xml \
--with-apache=../apache_1.3.29 \
--enable-track-vars \
--with-gd \
--enable-discard-path \
--enable-bcmath \
--enable-gd-native-tt \
--with-freetype-dir=/usr/local \
--with-png-dir=/usr/local \
--with-jpeg-dir=/usr/local \
--with-zlib=/usr/local \
--enable-apc
from all the included extensions mysql seems to be the only one with
references to SIG_ALRM.
I will continue looking but currently the only solution that worked for
me is setting the timeout on send's.
please let me know if you were able to reproduce this.
------------------------------------------------------------------------
[2003-12-02 13:22:07] [EMAIL PROTECTED]
The timeouts are already being set around the entire PHP processing
block look at mod_php4.c line 611 and lower.
You suggestion would force a timeout setting around every single write,
making things extremely slow, current code already should handle the
situation you describe.
------------------------------------------------------------------------
[2003-12-02 11:53:10] hexer at studentcenter dot org
To reproduce this problem one needs to start loading a php page and
force an ungraceful disconnection before the page is done loading. The
easiest way to force an ungraceful disconnection is to unplug the
computer from the internet as soon as the page is requested by the
browser.
As the result, php will keep trying to write data to the socket and
will eventually block until the operating system's default socket
timeout is reached.
The following script will do the job:
<?php
for($i = 0; $i < 1000000; $i++) {
echo "XXXXXXXXXXXXXXXXXXXXXXXX<br>\n";
}
?>
This should work on virtually any UNIX configuration with mod_php
compiled into apache 1.3.x.
It is important that the client's connection is broken ungracefully
instead of just being closed, that way the operating system has no way
of knowing that the connection with the client is no longer valid.
Normally apache will give up after trying to send for N seconds
specified in the Timeout directive of httpd.conf. Apache 1.3.x modules,
however, must explicitly make API calls that start and stop the timer to
mark the sections of the code where send's take place.
This problem can be reproduced with the default http.conf and php.ini
on apache 1.3.29 and mod_php 4.3.4 it has also been observed on earlier
versions of php and apache.
httpd.conf can have the following setting:
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
also to easilly see the processes be sure to enable mod_status by
uncommenting the following lines in httpd.conf
AddModule mod_status.c
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
# Deny from all
Allow from all
</Location>
from the status page you can see the process getting stuck on 'W'
status for a much longer duration than Timeout setting:
45-7 32133 0/50/3553 W 0.38 895 0 0.0 0.23 10.62 151.204.xxx.xxx
test.mydomain.com GET /test.php HTTP/1.1
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26494
--
Edit this bug report at http://bugs.php.net/?id=26494&edit=1
