Re: wait and SIGSTOP

[Hadrien Lacour <hadrien.lacour@xxxxxxxxxx>]

On Wed, Nov 14, 2018 at 01:34:10AM +0100, Hadrien Lacour wrote:
> On Mon, Nov 12, 2018 at 05:08:15PM +0100, Hadrien Lacour wrote:
> > Hello,
> >
> > after reading https://www.mail-archive.com/dash@xxxxxxxxxxxxxxx/msg00683.html,
> > I still wonder what the correct behaviour is supposed to be. The last message
> > lets me think that untrapped signals shouldn't interrupt wait. With the script
> >
> >     #!/bin/dash
> >
> >     sleep 100 &
> >     echo $!
> >     wait $!
> >     echo status: $?
> >
> > wait still exits immediatly with status 128 when I kill -STOP the output pid
> > . The other shells I tested still wait for the job and give me:
> > * bash: 143
> > * zsh: 147
> > * busybox ash: 143
> >
> > (this was using dash 0.5.10.2)
> >
> >
> > Sincerly,
> > Hadrien Lacour
>
> After some more testing, I'm even more confused, here's what I get when
> 1) running kill -STOP then kill -CONT on sleep
> 2) running kill on sleep
>
> +-------------+-------------------------------+------+
> | shell       | kill -STOP; kill -CONT        | kill |
> +-------------+-------------------------------+------+
> | zsh         | 147                           | 143  |
> +-------------+-------------------------------+------+
> | bash        | 0                             | 143  |
> +-------------+-------------------------------+------+
> | busybox ash | 0                             | 143  |
> +-------------+-------------------------------+------+
> | dash        | 128 (SIGSTOP interrupts wait) | 143  |
> +-------------+-------------------------------+------+
>
> After reading `man 1p wait` more carefully, I think that bash and busybox ash
> have the correct behviour.

Here's a way to test it without touching anything:

> for sh in zsh bash dash "busybox ash"
do
$sh test.sh &; sleep 0.5; pid=$(cat sleep.pid); kill -STOP $pid; sleep 0.5; kill -CONT $pid; wait $!
$sh test.sh &; sleep 0.5; pid=$(cat sleep.pid); kill $pid
done 2>/dev/null| grep '^status'