Re: Shell script terminates when spawning and killing a background shell process

Thank you for clarification and explanation!

Well, the remaining point is not about ksh but that this happens with 
default /bin/sh which one might expect to be stable.

- Gerhard


On 7/18/26 15:35, Robert Elz wrote:
>      Date:        Sat, 18 Jul 2026 13:53:10 +0200
>      From:        Gerhard Rieger <[email protected]>
>      Message-ID:  <[email protected]>
> 
>    | I have reduced the case to the following ksh script that terminates when
>    | it kills its background process, this happens on NetBSD 9.3 and NetBSD
>    | 10.1; when you don't think this script should print "SURVIVED"
>    | this issue might be a feature though...
> 
> Not a feature...
> 
>    | #! /bin/ksh
>    |
>    | /bin/ksh -c "sleep 2" </dev/null &
> 
> This seems to be causing the problem, replace that ksh with sh bash
> (or probably any other shell) and it all works, regardless of
> which shell is running the outer script.   While it is running
> ksh as the background process, it is also irrelevant which shell
> is running the outer script, that shell is killed.
> 
> The only rational explanation for this is that the ksh is killing
> its parent when it is sent the SIGTERM.
> 
> Note that unlike most other shells, our ksh isn't smart enough to
> recognise that with just "sleep 2" as a command, it can just exec
> that, rather it forks, and runs the sleep as a child.
> 
> While it is doing that, it blocks SIGTERM.   When the kill command
> is run, the signal is sent to that ksh (not the sleep), which achieves
> nothing immediately.  Later after the sleep has finished, the SIGTERM is
> unblocked in that ksh, and the ksh realises that it was supposed
> to be killed.   At that point it kills its parent (maybe it kills
> its own process group, which would include its parent in this case).
> 
> Our ksh is full of bugs, there are better ksh versions in pkgsrc if
> you want one of those (even a pdksh, which probably has less bugs
> that our version).   It kind of works, but no-one seems to interested
> in ever fixing any of the bugs it does have, I'd simply avoid it.
> 
> kre
>