On 2/1/24 8:25 AM, Adam Weremczuk wrote:
Hi Sherrard,
My index.html is super simple:
sorry if i wasn't clear. i was asking if you had the version with the
absolute path posted on your site. no matter, see the below.
After I replace:
img src="ms-logo.png"
with
img src="/var/www/html/h
On 1/31/24 3:11 PM, Sherrard Burton wrote:
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 w
On 1/31/24 06:24 AM, Yann Ylavic wrote:
On Tue, Jan 30, 2024 at 8:24 PM Sherrard Burton 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
On 1/31/24 02:26 PM, Adam Weremczuk wrote:
I've already tried replacing relative path to the image with absolute
but it made no difference.
Any ideas?
do you have a live example with the absolute path? the broken ones that
i looked at all had the relative paths which (understandably) d
] XXX: exited
[Tue Jan 30 19:10:50.367124 2024] [mpm_event:notice] [pid 151382:tid
140267709454016] XXX: exited
On 1/30/24 06:09 AM, Yann Ylavic wrote:
On Tue, Jan 30, 2024 at 11:54 AM Yann Ylavic wrote:
On Tue, Jan 30, 2024 at 4:37 AM Sherrard Burton wrote:
i was going to add some debu
On 1/29/24 12:25 PM, Yann Ylavic wrote:
That's where we are, I think, if this first/light patch eventually
helps significantly with the "local" graceful-stop which you care
about still, it's possibly worth it since it requires no opt-in (but
needs testing..), but going further looks overkill/
On 1/29/24 10:17 AM, Yann Ylavic wrote:
On Mon, Jan 29, 2024 at 3:06 PM Eric Covener wrote:
The patch helps in this case because we no longer close the listening
sockets unconditionally, I mean without first checking if there are
new connections in the backlog. So I thought the option was ne
On 1/29/24 9:05 AM, Eric Covener wrote:
Maybe I wasn't clear enough but this patch makes sense only if there
is something in place that prevents new connections from arriving at
the stopping httpd children processes (like a frontend/load-balancer
or a tcp/bpf filter), otherwise they may never
On 1/29/24 8:59 AM, Yann Ylavic wrote:
Maybe I wasn't clear enough but this patch makes sense only if there
is something in place that prevents new connections from arriving at
the stopping httpd children processes (like a frontend/load-balancer
or a tcp/bpf filter), otherwise they may never
Eric,
thanks for the quick reply. follow-up inline below:
On 1/27/24 09:46 PM, Eric Covener wrote:
apache2: 2.4.56-1~deb11u2, prefork MPM, mod_perl
I think it's a large window on prefork where this can happen. If any
process is busy processing a request, it cannot close its copy of the
listen
good day all,
i have an issue where for a small subset of requests issued during a
graceful-stop the client is not receiving connection refused (immediate
[RST,ACK] after [SYN]), nor receiving a full response, but the client is
rather completing the handshake, receiving an [ACK] after being all
please forgive me if this is the wrong place for this question, or if
this has been discussed elsewhere. i searched most of the night and
morning, and then started pouring through the source code, and i'm
pretty sure i've isolated the "issue" but need some advice as to where
to go.
we have be
12 matches
Mail list logo
