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 worked
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 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 '[S.]'; grep -Fh 'accept4'
>
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
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 debugging lines, but when i took a quick look at
> > the patch, i wasn't clear on which sections of the code i should be
> > guaranteed to hit. can you
On Tue, Jan 30, 2024 at 4:37 AM Sherrard Burton wrote:
>
> i was going to add some debugging lines, but when i took a quick look at
> the patch, i wasn't clear on which sections of the code i should be
> guaranteed to hit. can you be so kind as to send an updated patch with
> some gratuitous
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
On Mon, Jan 29, 2024 at 4:59 PM Sherrard Burton wrote:
>
> 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
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
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
On Mon, Jan 29, 2024 at 4:21 PM Eric Covener wrote:
>
> > > It seems to me If there is no such LB/VIP that stops new connections
> > > from landing on this server, the new option should be avoided.
> >
> > Correct.
> >
> > > But if there is such a LB/VIP, the option is not really needed. Is it
> > It seems to me If there is no such LB/VIP that stops new connections
> > from landing on this server, the new option should be avoided.
>
> Correct.
>
> > But if there is such a LB/VIP, the option is not really needed. Is it fair?
>
> The patch helps in this case because we no longer close
On Mon, Jan 29, 2024 at 3:06 PM 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
> 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 really stop which does
> not help
On Mon, Jan 29, 2024 at 2:23 PM Yann Ylavic wrote:
>
> On Sun, Jan 28, 2024 at 5:26 AM Sherrard Burton wrote:
> >
> > On 1/27/24 09:46 PM, Eric Covener wrote:
> > >
> > > Both worker and event MPMs have a dedicated listener thread per child
> > > process, so it will close those copies of the
On Sun, Jan 28, 2024 at 5:26 AM Sherrard Burton wrote:
>
> On 1/27/24 09:46 PM, Eric Covener wrote:
> >
> > Both worker and event MPMs have a dedicated listener thread per child
> > process, so it will close those copies of the listening sockets much
> > more quickly.
>
> so that i am clear, are
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
> 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
listening socket. The OS will continue to complete TCP connections and
acknowledge (some) data with nobody
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
20 matches
Mail list logo
