Skip to content

Concurrent child processes trigger unnecessarily backtrace #8082

Description

@alexey-tikhonov

When multiple child processes are run in parallel, any SIGCHLD event invokes handlers of all active child contexts:

(4:00:19): [be[...]] [child_handler_setup] (0x2000): [RID#2429] Setting up signal handler up for pid [684389]
(4:00:19): [be[...]] [child_handler_setup] (0x2000): [RID#2429] Signal handler set up for pid [684389]

(4:00:19): [be[...]] [child_handler_setup] (0x2000): [RID#2431] Setting up signal handler up for pid [684397]
(4:00:19): [be[...]] [child_handler_setup] (0x2000): [RID#2431] Signal handler set up for pid [684397]

(4:00:19): [be[...]] [child_sig_handler] (0x1000): [RID#2431] Waiting for child [684397].
(4:00:19): [be[...]] [child_sig_handler] (0x0020): [RID#2431] waitpid did not find a child with changed status.
(4:00:19): [be[...]] [child_sig_handler] (0x1000): [RID#2429] Waiting for child [684389].
(4:00:19): [be[...]] [child_sig_handler] (0x0100): [RID#2429] child [684389] finished successfully.

Naturally, only one context handler will process it, but other handlers will log "waitpid did not find a child with changed status" on SSSDBG_CRIT_FAILURE level triggering a backtrace.

Depending on the order of events, logged error can also be:

[child_sig_handler] (0x0020): [RID#2508] waitpid failed [10][No child processes].

Solutions range from simply changing log level to reworking code to use a single handler registered that would own a list of contexts.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions