The PDEATHSIG flag is indeed cleared for the child of a fork, but
preserved across calls to execve.
If there was a way to avoid this and propagate the flag across all
descendants, I think it would mess up processes that expect their
children to outlive them.
The rationale for this feature proposal is to be able to avoid leaving
orphan processes behind ; how said processes manage their own children
is up to them.
There's another reason the shell option is not a good idea though ; it
tells Bash to set the PDEATHSIG flag on all direct children, but we
might want to set the flag only for some specific children. Hence the
"run_with_pdeathsig" builtin that sets it only for the child created to
execute the command.
If target-specific features are an issue, I won't push that proposal any
further.
On 12/11/2023 06:36, Oğuz wrote:
On Saturday, November 11, 2023, Corto Beau <corto.b...@laposte.net> wrote:
Do you mean something like a "fork_noreparent" builtin that would
call make_child and set PDEATHSIG afterwards, or a "noreparent"
builtin that the child would have to call ?
I don't have a preference for either. I oppose it being a shell option
because first, it's a single function call that works on only one
target platform; and second, its effect doesn't seem to stick. If I'm
not missing anything, if I enable the proposed noreparent option in a
shell and run a command, and that command forks, its children won't
receive the death signal when the shell dies. It doesn't make any sense.
Unless there is a way to make it stick and affect all descendants of
the shell process, I don't think this would be very useful as a
loadable builtin either.
--
Oğuz
