Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Alejandro Colomar]

On 11/9/22 21:36, Paul D. Smith wrote:

Follow-up Comment #18, bug #63307 (project make):

I can see an argument for both sides ("give up immediately" and "run to
completion").  Most likely it's one of those things where different people
legitimately want different behaviors.

But I think that since all previous versions of GNU Make used the "give up
immediately" model, and it wasn't our intention to specifically change that,
we should preserve that behavior until/unless someone wants the opposite
behavior.

If we have "give up immediately" and you want to guard against that, you can
do so (say, redirecting output to /dev/null or whatever).  If we have "run to
completion" and that's not what you want, you don't have any way to get "give
up immediately" (unless we introduce an option which I don't want to do).

Not to mention the advantage that it's a much simpler (trivial) change to go
back to "give up immediately" :).


Not that I care about the behavior in this corner case, but was reading the list 
and thought of this:


You can actually get a rough guess of the intention of the user:

If -i or -k was used, "run to completion" is probably wanted; otherwise, "give 
up immediately" makes sense as a default.


No need for new flags.  Yes, this is reinterpreting the options for more than 
they were originally purposed, but in my head it makes sense. :)


Cheers,

Alex
--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Philip Guenther]

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov 
wrote:

> Follow-up Comment #6, bug #63307 (project make):
>
> > If SIGIGN was ignored before make was started though, it should remain
> ignored, even for make's children, see also
>  in
> reply
> to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
> patch re-enables it in that case?
>
> My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
> process. See https://pubs.opengroup.org/onlinepubs/9699919799/,
> specifically
> "Signals set to be caught by the calling process image shall be set to the
> default action in the new process image (see )."
>
> This desire to have the default disposition is intentional. Some of the
> reasons are explained in update 2. Other reasons are the desire to avoid
> complexity in make. Especially when there is no clear need for that
> complexity.
>

This is a change in behavior: previously, make didn't alter the disposition
of SIGPIPE and a build system could set it to SIG_IGN and have all the
invoked recipes inherit that.  As part of saying that make will ignore
SIGPIPE, you've decided to impose a rule that the rest of the build system
has to deal with it in the recipes instead of permitting a pass-through.
That's an unnecessary and user-unfriendly imposition.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.
>
> 1. That patch fails to restore the disposition in the case of make
> re-executing itself (in order to read an updated makefile).
> This could be fixed by calling sigaction before execve, but that'd not be
> atomic.


> 2. That patch uses posix_spawnattr_setsigdefault to set the disposition
> for a
> child process (when make uses posix_spawn). This fails the purpose of the
> patch, if make was invoked with sigpipe disposition of SIG_HOLD.
>

(SIG_HOLD?  That's not a real disposition (in posix) but rather part of an
obsolete version of a mechanism standardized as sigprocmask() and
orthogonal to the disposition (ignore/default/catch).)



> Fixing those deficiencies is not that cheap. In the end, i didn't see any
> benefit for make to go through that trouble of restoring sigpipe
> disposition
> for its children and i proposed this simple fix.
>
> Unlike attempts to restore, one nice property of the sighandler patch is
> that,
> if more calls to exec are introduced to make, the patch will still work for
> all of them.
>

Setting the disposition of SIGPIPE to be caught with a do-nothing routine
is a good idea.  Can you just skip that if the disposition is SIG_IGN at
start?  Then a SIG_IGN will be inherited but the disposition will otherwise
be reset by execve.