suspected bug in timeout command

[Raffaello D. Di Napoli]

On 3/1/22 16:57, Denys Vlasenko wrote:
> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko 
> <vda.linux at googlemail.com> wrote:
>> Meanwhile: what "timeout" is doing is it tries to get out
>> of the way of the PROG to be launched so that timeout's parent
>> sees PROG (not timeout) as a child. E.g. it can send signals
>> to it, get waitpid notifications if PROG has been stopped
>> with a signal, and such.
>>
>> And PROG also has no spurious "timeout" child.
>> "timeout" exists as an orphaned granchild.

That doesn’t seem to be a concern for coreutils, according to Rob’s 
inspection. (I haven’t looked, but I’ll assume they still do signal 
forwarding and everything that can be done cheaply.) Isn’t it a goal of 
BB to avoid unnecessary divergence from coreutils?


>> Let's go with a solution with fd opened to /proc/PID?

I’d think simplifying the implementation and bringing it closer to 
coreutils’ would be more in line with BB’s goals, instead of making it 
larger and more complicated (especially considering how 
counter-intuitive it is already, despite being fairly small).


Also, that would add dependency on procfs being mounted (and configured 
in the kernel ;)


> It would still be possible for the watched process to exit
> right before "timeout" decided to SIGTERM it,
> another process to fork and reuse this pid, and get
> this SIGTERM instead.

That seems… undesirable, if even less likely than the original issue.

-- 
Raf