suspected bug in timeout command

[Michael Conrad]

On 2/12/22 07:38, Michael Conrad wrote:
> Correctly using pidfd *still* requires that you be the parent process, 
> else the child could get reaped and replaced before the pidfd is 
> created.  As far as I can tell, the only purpose of pidfd is for 
> waking on poll() instead of using signals, which is orthagonal to this 
> problem.
>
> I haven't looked at the source in busybox yet, but it boggles my mind 
> that it wouldn't just be a simple fork+alarm+waitpid because that is 
> literally the least code implementation, and race-free.
>
> -Mike C
>
Sorry for being lazy.  I looked at the source and this is the reason:

/* We want to create a grandchild which will watch
  * and kill the grandparent. Other methods:
  * making parent watch child disrupts parent<->child link
  * (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" -
  * it's better if service_prog is a child of tcpsvd!),
  * making child watch parent results in programs having
  * unexpected children.    */

I don't follow this reasoning.  Does "disrupts the parent<->child link" 
just about sending signals?  If the timeout app relays all signals from 
itself to the child, what remaining problems would exist?

-Mike C