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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
