suspected bug in timeout command

[Michael Conrad]

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