[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] Trapped signals in cron and login environm
Re: [Savannah-hackers-public] Trapped signals in cron and login environment
Sat, 6 May 2017 15:39:32 -0700
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
> 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 :-)