Re: posix_spawn: parent can get stuck in uninterruptible sleep if child receives SIGTSTP early enough

[Rain <glibc@sunshowers.io>]

On Mon, Aug 22, 2022, at 09:51, Adhemerval Zanella Netto wrote:

<snip>

>> ---
>> 
>> Based on these backtraces and reading the source code, here's what I believe is happening:
>> 
>> 1. The parent calls __posix_spawnp, which in turn calls __spawni and __spawnix.
>> 2. The parent calls clone3 and enters uninterruptible sleep.
>> 3. The child enters __spawni_child and blocks all incoming signals.
>
> In fact glibc do not block, but rather set all handlers to either SIG_DFL
> if is not SIG_IGN, or SIG_DFL if POSIX_SPAWN_SETSIGDEF is set.  However
> it does not matter for SIGSTOP since we can not set it to SIG_IGN.
>
>> ---> 4. At this point the child receives a SIGTSTP signal. <---
>> 5. The child unblocks signals by calling sigprocmask/pthread_sigmask.
>> 6. At this point the SIGTSTP is delivered to the child.
>
> Afaik SIGSTOP is not synchronous and can be delivered any time during process
> execution. 

Thank you for the response! To be clear, I'm referring to SIGTSTP (Ctrl+Z) [1], not
SIGSTOP. I understand that SIGSTOP cannot be blocked. However, SIGTSTP (which is
a different signal which can be blocked) is what I'm concerned about.

>
>> 7. However, the clone hasn't exited in the parent and so it remains stuck in the clone3 syscall until the child receives a SIGCONT.
>> 
>> I'm not sure what a reasonable way to handle this would be on the part of my CLI tool. The tool currently just gets stuck in uninterruptible sleep, resulting in a bad user experience.
>
> Reading through both your twitter discussion and the bug report against your
> tool [1] I think it is outside posix_spawn specification on how to handle
> SIGSTOP for the helper process itself in the tiny window between process
> creation and the setpgid.
>
>> 
>> Here are solutions I've thought about that don't seem to work (please correct me if I'm wrong!)
>> 1. Setting the signal mask to include SIGTSTP. I do want to be able to send the child SIGTSTP after the clone(), and in my case the child is a third-party process so I can't depend on it to reset the signal mask.
>> 2. Spawning a stub process that execves the real child. It seems like the same issue exists when the main process calls the stub process, if I'm understanding the code correctly, so this won't help.
>> 
>> ... though now as I'm writing this email out, maybe one solution is:
>> 
>> * my tool spawns a stub process with SIGTSTP masked.
>> * the subprocess unmasks SIGTSTP (so it could receive the SIGTSTP here, but at least it won't block the parent process), then execves the third-party process.
>> 
>> Is that the solution you would recommend?
>
> I am not sure this would work, since SIGSTOP cannot be caught, blocked, or 
> ignored.  What I think if might work is to spawn a stub process and make
> it a new session leader with setsid so it will not have a controlling
> terminal.  The stub process will be responsible to spawn new processes,
> so any interaction with the controlling terminal (the CTRL+Z) won't affected
> the posix_spawn helper thread. 

That is definitely an interesting solution. However, is it necessary given that
Ctrl+Z is actually SIGTSTP, which can be blocked?

Thanks again.

[1] https://www.gnu.org/software/libc/manual/html_node/Job-Control-Signals.html

>
> You will probably need to open the controlling terminal in raw mode so you
> can catch ctrl-z and pass along the expected process groups.
>
>> 
>> Thanks.
> 
>
> [1] https://github.com/nextest-rs/nextest/pull/470#issue-1338100182

-- 
Rain
(they/she)