The Wireshark trace confirms what one may have predicted from the
observed symptoms. There is no response from the server to the GET
request on the wire. The pcap file and dissected text file were sent to
Yann privately.
I've now also tried with "EnableMMAP Off" and this makes no difference.
The problem does not occur for all files. I have not done an exhaustive
test with all our static files, but it seems that the problem
occurs primarily with small files. For example, these two files cause
the lock-up:
-rw-rw-r-- 1 root naadmin 2509 Jan 19 14:10 css/home_styles.css
-rw-rw-r-- 1 root naadmin 1698 Jan 19 14:10 css/subpage.css
These three files work fine:
-rw-rw-r-- 1 root naadmin 6478 Jan 19 14:10 css/application.css
-rw-rw-r-- 1 root naadmin 3991 Jan 19 14:10 css/homepage.css
-rw-rw-r-- 1 root naadmin 1239621 Jan 19 14:10 jar/jconfig.jar
Joachim
On 2016-02-01 12:34, Joachim Achtzehnter wrote:
On 2016-02-01 4:19, Yann Ylavic wrote:
This restores the previous (pre 2.4.18) behaviour of flushing
output on every read, which I'd prefer to avoid, if possible.
Could you provide some network capture (tcpdump, wireshark...) when
the lock-up occurs?
I'll work on capturing this, in the meantime I tried your patch
below.
Is EnableMMap somehow always involded here (you mention it in the
original message)?
I had mentioned this because we have some requests passed through a
custom handler, not serviced from the filesystem, and these never
seem to exhibit the problem. All the failing requests I've debugged
were serviced by Apache itself directly from the filesystem, and
Apache used mmap for this. I can try disabling mmap to see if the
problem goes away.
That would help to build a reproducer...
Maybe the attached patch could be "enough" to fix the issue?
It does not. The behaviour is exactly as with the original 2.4.18
version. Note, that the problem is reproduced consistently. Requests
that get stuck always get stuck every time I try to repeat it. If
this was somehow related to renegotiation, would it not be more
variable?
This patch also includes some minimal logging (level NOTICE) to
help diagnose in case of lock-up, still.
The log output for a failing request is attached.
Thanks,
Joachim
--
joac...@kraut.ca http://www.kraut.ca