On 2/9/22 12:12, Baruch Siach wrote:
Hi Sun,
On Wed, Feb 09 2022, סאן עמר wrote:
Hi, I'm using busybox for a while now (v1.29.2). and I had an issue with a
sigterm send randomly to a process of mine. I debugged it until I found
it from the timeout process which was assigned before to another process with
the same pid. (i'm using a lot of timeouts for a lot of jobs)
so i looked at the code, "timeout.c" file where it sleep for 1 second in each
iteration then check the timeout status. I suspect at this time the
process timeout monitoring is terminated, but another one with the same pid is
already created. which creates unwanted timeout.
There is a comment in there about sleep for "HUGE NUM" will probably result in
this issue, but I can't see why it won't occur also in the current
case.
there is no change of this behaviour in the latest master.
i would appreciate any help, sun.
Any reference to PID number is inherently racy. There is no solution for
your problem in the traditional POSIX API.
PIDs are not racy if they are sent by the parent process. Since the
timeout command starts the other command, and waits to kill it, it
should be the parent process, and will always reliably know that either
the child is not reaped and can be sent a signal, or that it is reaped
and there's no reason to. Perhaps the implementation of this command
needs corrected?
-Mike C
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
