On Mon, Jan 29, 2024 at 4:21 PM Eric Covener <covener@xxxxxxxxx> 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 fair? > > > > 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 needed > > because if nothing stops new connections from arriving it could > > prevent the child from stopping indefinitely? How could we know if a > > LB/VIP is in place? > > I mean the initial patch vs. the status quo, not just the opt-in part. Even if there is a LB that stops routing new connections to the stopping httpd we might kill the ones that are in the backlog already. But yes I suppose that the switch on the LB could precede the graceful-stop by a few seconds to let httpd drain the backlog normally, in any case the race is hardly addressable fully in httpd so we might consider doing nothing to minimize it too, that's fair enough :) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx