Reading compressed character maps and gzip EPIPE issues.

[Carlos O'Donell]

On 11/23/19 8:27 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 11/20/19 11:52 PM, Paul Eggert wrote:
>>> On 11/20/19 8:43 PM, Carlos O'Donell wrote:
>>>> Paul, Any suggestions?
>>>
>>> Yes: don't ignore SIGPIPE in the process that execs gzip. That way,
>>> gzip will be killed without having a chance to complain to stderr.
>>> This is the same for gzip 1.9 as for 1.10.
>>
>> I'm not actually sure what we do with SIGPIPE in localedef. I'll have
>> dig into that. Thanks for the pointer.
> 
> Sorry, Paul is right: This is not a localedef problem at all.  You
> need to fix the process that spawns localedef.  It somehow ends up
> blocking the signal.

I see two issues needing investigation.

Is localedef wrong in that it doesn't set SIGPIPE to SIG_DFL at startup?
~~~ exec:
This volume of IEEE Std 1003.1-2001 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 co-operating) programs.
~~~

Current localedef uses posix_spawnp, which uses vfork, which blocks
all signals while it starts the child. Should we be setting the
signal mask appropriately for posix_spawnp so SIGPIPE can reach
gzip? Is that what we're getting at?

-- 
Cheers,
Carlos.