On Mon, Jan 29, 2024 at 4:59 PM Sherrard Burton <sburton@xxxxxxxxxxxxx> wrote: > > On 1/29/24 10:17 AM, Yann Ylavic wrote: > > On Mon, Jan 29, 2024 at 3:06 PM Eric Covener <covener@xxxxxxxxx> 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 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? > > it sounds like this issue is all but resolved, but i would like to > understand whether the above (preventing the child from stopping > indefinitely) is an actual possibility. > > my (naive) expectation is that if a given child has been signaled while > handling an existing request then it "knows" not to accept() a new > request after completing the existing request. so it seems that the > child is not under any danger of continuing indefinitely, regardless of > the contents of the backlog. Yes, a stopping child won't accept any new connection currently in httpd, but this is what I proposed to change: each child continues to accept new connections after the graceful signal, until there is nothing to accept anymore. Though this needs an opt-in obviously. Sorry for the confusion because this is not what the patch I initially proposed is doing either, the patch simply allows for one more try at emptying the backlog after the signal was received, so it won't by itself prevent the child from stopping, but it might (likely) not be enough if resets don't happen mainly because of some bad timing in the listener thread (which this patch addresses, only). So before we go to the opt-in, as Eric said, we might as well consider that since it's not fully addressable in httpd anyway (without races), we'd rather let this be handled outside httpd (better/fully). 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/risky for httpd. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|