On Thu, Apr 14, 2022 at 12:09 PM Ruediger Pluem <rpl...@apache.org> wrote: > > On 4/14/22 11:52 AM, Yann Ylavic wrote: > > > > Any signal that killed the process would mean something unexpected > > happened since we clean_child_exit() otherwise? > > Hm. You mean that the case for > > case SIGTERM: > case SIGHUP: > case AP_SIG_GRACEFUL: > > in ap_process_child_status > never triggers as the child catches these and does a clean_child_exit()?
Yes > > If yes, the above seems to be a simple solution, but it would also capture > SIGKILL which might > have been issued by our parent. Does this matter? I think our SIGKILLs (for ungraceful restart) are "captured" by ap_reclaim_child_processes(), that is outside server_main_loop() so it should be OK.. > > Do we need something for processes that die due to MaxConnectionsPerChild or > do we expect them to die at a slow path where the > current approach is fine? Hm, good question. Restarting them if not necessary from a maintenance metrics perspective is no better/worse than waiting for a maintenance cycle, so I'd say let them be maintained as we do now.. Ideally (maybe) we'd pass a timeout to ap_wait_or_timeout() to make sure that maintenance cycles really happen every 1s, regardless of exited processes in the meantime (i.e. handle a "remaining" timeout instead of the hardcoded 1s which currently may result in 0.9s+waitpid()+0.9s+waitpid()+timeout thus here ~2s but possibly more between two maintenance cycles). > > Regards > > Rüdiger
