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." https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
Attachment:
signature.asc
Description: OpenPGP digital signature