Re: [musl] [bug] Ctrl-Z when process is doing posix_spawn makes the process hard to kill

[Rich Felker <dalias@libc.org>]

On Fri, Jan 17, 2025 at 09:55:50PM +0400, Askar Safin wrote:
> Thanks a lot for answer!
> 
>  ---- On Fri, 17 Jan 2025 10:37:09 +0400  Rich Felker  wrote --- 
>  > Note that SIGSTOP, which is not blockable interceptible or ignorable,
>  > can't be handled this way, but the pid has not yet leaked to anything
>  > at this point, so the only way SIGSTOP can be generated is by a badly
>  > behaved program signaling random pids, which is not a case that needs
>  > to be handled gracefully.
> 
> But what if somebody sends SIGSTOP to whole process group using kill(2)?
> 
> The bug is not reproducible with fork. Maybe this is kernel bug and should be
> forwarded there instead?

I don't understand what you think the kernel bug is. AFAICT it's
behaving exactly as it should. The spawn impl just isn't using the
kernel primitives exactly right.

Since SIGSTOP is an issue, I don't think my previous idea of using
no-op signal handlers makes sense. We'll have to handle an unblockable
stop situation anyway so might as well use the same for blockable
stops.

So, I think the parent, while waiting for the fd close event from the
child, also needs to watch for child status change to stopped, and if
this happens, send SIGCONT. This is unfortunately gratuitously
difficult, since we don't have a primitive to wait for
fd-activity-or-pid-activity short of depending on pidf (if this even
works; does pidfd poll readable for transition to stopped state?).

If there is a working pidfd approach, I guess we should use that, and
fallback to polling with short timeout and doing a waitpid/WNOHANG
between polls if pidfd isn't obtainable.

Rich