On 1/31/24 06:24 AM, Yann Ylavic wrote:
On Tue, Jan 30, 2024 at 8:24 PM Sherrard Burton <sburton@xxxxxxxxxxxxx> wrote:i have confirmed that the patch has been applied, and the behavior still persists, as confirmed by comparing the counts of [SYN,ACK] and accept() ~$ tcpdump -n -r /tmp/tcpdump.pcap | grep -Fc '[S.]'; grep -Fh 'accept4' /tmp/strace-apache2.out.* | grep -Fc .240.209 reading from file /tmp/tcpdump.pcap, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 Warning: interface names might be incorrect 3485 3483This means those two connections came in (or were made available by the system) after the last accept() call, which is the race condition that httpd can do nothing about unfortunately. How much does it improve compared to non-patched httpd, how many reset connections without the patch? If not significant I don't think it's worth attempting to do something about it..
two is about par for the course _when there are resets_. but it doesn't necessarily happen on every test run. for example, after initially applying the v1 patch (and having fully composed a response to say that the patch seemed to have worked :-)), i discovered that i had forgotten to switch back from prefork to event. ie, i ran the test a few times in a row with no resets, even though the patch was not in play.
i have not previously, but i will try to gather some statistics about number of resets per failed run and failed vs successful runs, since the combination of the two is needed to make any quantitative assessment.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|