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 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.
Yann,thank you for the feedback and the thorough explanation (i hadn't thought about the OS-level backlog). after discovery of this problem i began removing the target server from the backend pool in the load-balancer before issuing the graceful-stop. this seems to work as expected for planned maintenance, but the problem can still occur if the backend server ends up needing to be stopped outside of my direct command.
we know that we cannot guard against all situations, but the systemd unit files on debian seem to trigger graceful-stop for its 'stop' action
ExecStop=/usr/sbin/apachectl graceful-stopso if indeed this were addressable within httpd (which it sounds like it is not) then we would theoretically be protected from all but unexpected hard crashes in httpd or at the OS level.
my takeaway at this point, not having yet finished reading Eric's other responses on this thread, is that this mostly "is what it is", and i think that i am (provisionally) satisfied with knowing that the behavior that i am observing is not a bug, per-se.
ps--is there any possibility of "shrinking" this window by tuning either ListenBacklog or any analogous settings at the OS level? or do i risk creating a different problem?
i ask because theoretically, the backlog/queuing (from the client perspective) should mostly be handled by the load-balancer, which is currently L4, not L7. so if reducing/eliminating the backlog on the server might positively impact this situation then i may spend some time on it.
thanks again --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|