bug-make
[Top][All Lists]
Advanced

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

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


From: Philip Guenther
Subject: Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children
Date: Sat, 5 Nov 2022 13:53:57 -0900

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov <INVALID.NOREPLY@gnu.org> 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
<https://lists.gnu.org/archive/html/bug-make/2022-11/msg00015.html> 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 <signal.h>)."

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]