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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 22/08/22 14:48, Adhemerval Zanella Netto wrote:

>>>
>>>> 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.
> 
> I think one possibility would to set the default signal actions to SIG_IGN, similar
> to POSIX_SPAWN_SETSIGDEF does for SIG_DFL (Solaris have POSIX_SPAWN_SETSIGIGN_NP
> as an extension).  It won't help much if the signal is received in the tiny window 
> between the helper process start and sigaction call, so I am afraid this will only 
> decrease the possibility of the deadlock, not eliminate it.

Sorry I got it backwards, since I forgot that glibc implementation does block
all signal prior spawning the helper process.  In fact using SIG_IGN as default
signal handling would require the spawn process to restore it to SIG_DFL, which
would prevent any process to be stopped.

Which goes back to your original suggestion:

> * 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.

Which I agree is a way to handle it, since we can not atomically unblock SIGTSTP
and execve.

I am not sure if this indeed characterize as a posix_spawn bug for glibc, since
to really fixing we would either need to go back to use fork or use something
like a helper process.