Re: [Savannah-hackers-public] Trapped signals in cron and login environment

[Jim Meyering]

On Thu, May 4, 2017 at 2:08 PM, Bob Proulx <address@hidden> wrote:
> I have been (slowly) chasing down some noise in the new Trisquel 7
> systems.  One of them is this message written to cron from one of the
> cronjobs every time it is run.
>
>   gzip: stdout: Broken pipe
>
> That is a sample.  Seeing the "Broken pipe" message I know immediately
> that SIGPIPE is inappropriately trapped.  So I look to see if it is
> trapped in the shell.
>
>   address@hidden:~# trap -p
>   trap -- '' SIGTSTP
>   trap -- '' SIGTTIN
>   trap -- '' SIGTTOU
>
> Huh?  The login environment sets up users with those job control
> signals ignored?  That's bad.  Why are those trapped?  That isn't
> normal.  But that isn't SIGPIPE.  Not being of help about the cron
> script problem I set up a very small cron test.  Because of course
> running the script from the command line doesn't produce any noise.
> The problem must be only when run from cron.
>
>   */2  * * * *   root /root/bin/trap-test
>
>   address@hidden:~# cat bin/trap-test
>   #!/bin/bash
>   exec >/tmp/out 2>&1 </dev/null
>   trap -p
>
>   address@hidden:~# cat /tmp/out
>   trap -- '' SIGPIPE
>
> As suspected SIGPIPE is being ignored for cronjobs.  That's bad.  (On
> my Debian system I find SIGINT ignored.  Not great either but doesn't
> cause the problems of SIGPIPE ignored.)
>
> Trapping SIGPIPE is one of the deja nu bugs that we see again and
> again.  It gets fixed.  Then someone decides to ignore SIGPIPE again
> elsewhere.  One of those wack-a-mole problems that just keeps
> appearing again and again in different places.  Sigh.
>
> The only way to really fix this bug is to find the parent process
> location where it is being ignored and to stop that happening.  Stop
> it from ignoring SIGPIPE.  I will keep walking up the process tree
> until I find where this is happening.  I pulled the Trisquel source to
> cron and it doesn't seem to be happening there.  Hopefully this
> doesn't go all of the way into the 'upstart' init system.
>
> Soo...  It looks like these indicate two independent and different
> signal handling bugs to find and fix.
>
> Just a communication update in case other folks are hitting signal
> problems too...

Ugh. Thanks for working on that and writing that up.

Brings back bad memories of tracking down similar issues :-)