On Mon, Jan 29, 2024 at 2:23 PM Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote: > > On Sun, Jan 28, 2024 at 5:26 AM Sherrard Burton <sburton@xxxxxxxxxxxxx> 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 you saying that this behavior is still possible, > > although less likely under the worker and event MPMs? > > I think it's possible regardless of the MPM, and there is quite little > a server can do about it without the help of the system or some > tcp/bpf filter (something that prepares the graceful shutdown at the > system level to prevent the 3-way handshake from completing). > This is because when the connections are ready to be accept()ed (i.e. > in the listening socket's backlog), they are already fully established > and likely contain the request data (at least partly), the system has > done this underneath httpd already. > So if/when httpd closes its listening socket(s) all the connections in > the backlog(s) are lost/reset anyway, and there is always going to be > a race condition with the draining of the backlog if nothing stops new > connections from being established at the system level. > > To minimize the race condition maybe httpd can do better at trying to > drain the backlog before closing the listeners. Does the attached > patch help for instance (it's against mpm_event 2.4.x)? > But I don't think it can be fully solved at httpd level anyway, with > this change the effective stop could be longer (so long as there are > incoming/pending connections routed to each child by the system), it > could even last forever theoretically if connections keep coming > indefinitely.. 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 for a graceful stop/restart obviously. So this change (if useful) should be guarded by a GracefulDrain on/off or something config option to not hurt the other use cases. > > Regards; > Yann. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|