Re: non-interactive sh and SIGTERM
Thanks for the explanation, it makes sense to use pgids for that purpose. In the case in which I am interested (vimtex plugin failing to kill latexmk, which works on another machine running debian linux) I guessed that the plugin sent a SIGTERM signal only to the 'sh -c' process, which would work with bash because bash somehow terminates the subprocess immediately. But I guessed wrong: vimtex uses vim's job_stop, which according to vim's help should send the signal to the process group, with the explicit intent of terminating 'sh -c' commands. So this issue comes from either vim or vimtex. On Sun, Nov 25, 2018 at 09:04:22PM -0800, Philip Guenther wrote: > On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi wrote: > > > 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. > > > > Hmm, why should it? If you wanted to kill whatever processes where started > from that invocation, shouldn't you send SIGTERM to the process group? > > > > > Philip, what was your test? > > > > : morgaine; sh -c 'while :; do :; done' & > [3] 16632 > : morgaine; kill 16632 > [3] - Terminated sh -c "while :; do :; done" > : morgaine; > : morgaine; sh -c 'while :; do sleep 1; done' & > [3] 59539 > : morgaine; kill 59539 > : morgaine; > [3] - Terminated sh -c "while :; do sleep 1; done" > : morgaine; > > sh itself doesn't ignore SIGTERM, but rather exits after receiving it. > > > Philip Guenther
Re: non-interactive sh and SIGTERM
On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi wrote: > 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. > Hmm, why should it? If you wanted to kill whatever processes where started from that invocation, shouldn't you send SIGTERM to the process group? > Philip, what was your test? > : morgaine; sh -c 'while :; do :; done' & [3] 16632 : morgaine; kill 16632 [3] - Terminated sh -c "while :; do :; done" : morgaine; : morgaine; sh -c 'while :; do sleep 1; done' & [3] 59539 : morgaine; kill 59539 : morgaine; [3] - Terminated sh -c "while :; do sleep 1; done" : morgaine; sh itself doesn't ignore SIGTERM, but rather exits after receiving it. Philip Guenther
Re: non-interactive sh and SIGTERM
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 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
Re: non-interactive sh and SIGTERM
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 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
Re: non-interactive sh and SIGTERM
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 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
Re: non-interactive sh and SIGTERM
On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi 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. Philip Guenther
non-interactive sh and SIGTERM
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.
