Sorry about the wrong report, I just tested again and I can see the same behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to the sleep process.
Philip, what was your test? Thanks On Fri, Nov 23, 2018 at 09:50:29AM +0100, Olivier Taïbi wrote: > After some testing, this issue does not seem to be directly caused by > ksh. Compiling ksh from a year ago, I get the same behaviour: SIGTERM is > not passed on to child. I'm not sure what to try next. Bisecting > /usr/src? > > On Fri, Nov 23, 2018 at 08:55:16AM +0100, Olivier Taïbi wrote: > > On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > > > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi <[email protected]> wrote: > > > > > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > > > The man page says that interactive shells will ignore SIGTERM, but does > > > > not mention the non-interactive case. > > > > > > > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > > > additional information for us to help you. > > > > Oops, I did not notice that sh ignores SIGTERM on my -current > > installation but not on 6.4 (different machine though). The minimal test > > is: > > sh -c 'sleep 1000' > > then kill this sh process. Nothing happens, but killing the sleep > > process terminates it. > > > > In fact it is not completely true that sh ignores SIGTERM, but it seems > > that it is waiting for the current running command to terminate on its > > own, rather than forwarding the signal. That is, after running > > sh -c 'while [ -z "" ]; do sleep 10; echo test; done' > > and sending SIGTERM to sh, it will terminate (and print 'Terminated') > > after the sleep is complete. > > > > I did not imagine this was recent because I thought that this behaviour > > was the reason for this bug: > > https://github.com/lervag/vimtex/issues/1032 > > that I can reproduce. > > > > Thanks for your help. > > > > > > > > Philip Guenther
