On 4/14/22 1:16 PM, Yann Ylavic wrote:
> 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..
Good point. Then I am fine with your proposed patch.
>
>>
>> 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).
Hm, but ap_wait_or_timeout only waits if there is nothing to reap, which would
mean we would wait at max 1 s (+ processing time
for multiple ap_wait_or_timeout calls) until we perform the idle server
maintenance, or do I miss your point?
Regards
Rüdiger
