httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Achtzehnter <>
Subject Re: HTTPS connections lock-up with 2.4.18
Date Mon, 01 Feb 2016 22:50:10 GMT
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


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


View raw message