On 4/14/22 11:52 AM, Yann Ylavic wrote:
> On Thu, Apr 14, 2022 at 11:21 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 4/13/22 5:41 PM, Yann Ylavic wrote:
>>> On Wed, Apr 13, 2022 at 4:30 PM Ruediger Pluem <rpl...@apache.org> wrote:
>>>>
>>>> While looking at PR65769 I stumbled across the below in event.c (same in
>>>> worker.c)
>>>>
>>>> 3460 /* Don't perform idle maintenance when a child dies,
>>>> 3461 * only do it when there's a timeout. Remember only a
>>>> 3462 * finite number of children can die, and it's pretty
>>>> 3463 * pathological for a lot to die suddenly.
>>>> 3464 */
>>>> 3465 continue;
>>>>
>>>> In case several processes or even all die by a segfault we would wait
>>>> until we have processed all that processes plus one second
>>>> until we start new processes. Shouldn't we perform an
>>>> perform_idle_server_maintenance in case the process died because of a fatal
>>>> signal?
>>>
>>> +1
>>>
>>
>> In order to solve this I would like to add another APEXIT_ constant (e.g.
>> APEXIT_FATAL_SIGNAL).
>
> Maybe something like:
>
> Index: server/mpm/event/event.c
> ===================================================================
> --- server/mpm/event/event.c (revision 1899818)
> +++ server/mpm/event/event.c (working copy)
> @@ -3462,7 +3462,9 @@ static void server_main_loop(int remaining_childre
> * finite number of children can die, and it's pretty
> * pathological for a lot to die suddenly.
> */
> - continue;
> + if (!APR_PROC_CHECK_SIGNALED(exitwhy)) {
> + continue;
> + }
> }
> else if (remaining_children_to_start) {
> /* we hit a 1 second timeout in which none of the previous
> --
>
> could do?
> 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()?
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?
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?
Regards
Rüdiger
