[PATCH] Suppress tr's stderr in the generate function

[Kjetil Torgrim Homme]

On 28/12/2020 14:21, Allan Odgaard wrote:
> On 28 Dec 2020, at 11:32, Nicolai Dagestad wrote:
> 
>> It might be something fishy with my machine, with:
>>     python -c "print('0'*4097)" | tr 0 1 | head -c 10
>> I get the broken pipe on my laptop, but on none of my other machines 
>> running arch...
> 
> Background:
> 
> In the above line `head` reads 10 bytes and then closes its stdin (which 
> is stdout for `tr`).
> 
> When a program writes to a closed pipe (stdout), it will receive SIGPIPE 
> which by default will terminate the process, so normally `tr` will be 
> terminated (silently) when nobody reads its output.
> 
> The reason for the 4096 bytes is due to buffering, `tr` can succesfully 
> fill up the buffer before triggering a SIGPIPE signal.
> 
> One can set SIGPIPE to be ignored, this will be inherited by a child 
> process during fork.
> 
> If SIGPIPE is being ignored, then it looks very much like `tr` *will* 
> output an error message, as then `fwrite` will fail and output an error 
> judging by this code: 
> https://github.com/coreutils/coreutils/blob/fb64712c4d79a542bae533034c6c4802eae555fd/src/tr.c#L1585-L1587 
> 
> 
> My theory: Someone has set SIGPIPE to be ignored, for the process that 
> spawns `pass` (and your test).

A small anecdote about this problem from 15 years ago:  I had a problem 
with the makewhatis cron job starting to emit mail to root about broken 
pipes (thousands of lines).  When I ran the job by hand, it all worked 
fine.  After a reboot, it also worked fine.

After quite a while of headscratching, the cause was found: When RPM 
(actually up2date) ran, it ignored the SIGPIPE signal (in order to close 
the rpmdb cleanly on write error).  If the cron package was updated, the 
cron daemon was restarted, with SIGPIPE still ignored.  Cron did not 
touch signal handlers during startup, so the result was that all cron 
jobs launched thereafter would get this very confusing behaviour.

These days systemd makes sure services are starting in a clean and 
consistent state, so this is less likely to crop up again :-)

-- 
Kjetil T. Homme
Redpill Linpro - Changing the Game