tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

SIGCHLD set to SIG_DFL on exec(3)

On 06.02.2020 20:51, Robert Elz wrote:
> Module Name:	src
> Committed By:	kre
> Date:		Thu Feb  6 19:51:59 UTC 2020
> Modified Files:
> 	src/bin/sh: main.c
> Log Message:
> If we are invoked with SIGCHLD ignored, we fail badly, as we assume
> that we can always wait(2) for our children, and an ignored SIGCHLD
> prevents that.   Recent versions of bash can be convinced (due to a
> bug most likely) to invoke us that way.   Always return SIGCHLD to
> SIG_DFL during init - we already prevent scripts from fiddling it.
> All ash derived shells apparently have this problem (observed by
> Martijn Dekker, and notified on the bash-bug list).  Actual issue
> diagnosed by Harald van Dijk (same list).

> +	(void)signal(SIGCHLD, SIG_DFL);

We are allowed to fix this in the kernel for everybody:

"If the SIGCHLD signal is set to be ignored by the calling process
image, it is unspecified whether the SIGCHLD signal is set to be ignored
or to the default action in the new process image."

"This volume of POSIX.1-2017 specifies that signals set to SIG_IGN
remain set to SIG_IGN, and that the new process image inherits the
signal mask of the thread that called exec in the old process image.
This is consistent with historical implementations, and it permits some
useful functionality, such as the nohup command. However, it should be
noted that many existing applications wrongly assume that they start
with certain signals set to the default action and/or unblocked. In
particular, applications written with a simpler signal model that does
not include blocking of signals, such as the one in the ISO C standard,
may not behave properly if invoked with some signals blocked. Therefore,
it is best not to block or ignore signals across execs without explicit
reason to do so, and especially not to block signals across execs of
arbitrary (not closely cooperating) programs."

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index