suspected bug in timeout command

[Raffaello D. Di Napoli]

On 3/2/22 03:50, Michael Conrad wrote:
> On 3/2/22 02:45, Raffaello D. Di Napoli wrote:
>> 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).
>
>
> It might be worth mentioning that busybox can't conform to coreutils 
> unless it does remain the parent process, because of this detail: 
> (from coreutils' timeout man page)
>
> > If the command times out, and --preserve-status is not set, then
> > exit with status 124.  Otherwise, exit with the status of COMMAND.

Well, yes. I already pointed out in an earlier message I see a rewrite 
as unavoidable, to really fix the reported issue. By “simplifying the 
implementation” now I meant redoing it so that it aligns not only with 
coreutils, but also with what _every single person who’s looked at it in 
this thread_ expected, i.e. the conventional parent/child relationship 
rather than a reverse grandchild/parent as it is today.


> timeout doesn't appear to be part of POSIX, though.

I don’t think POSIX would include verbiage that would directly impart a 
design to a utility other than its arguments and expectations. However 
BB should be compelled to avoid a design vulnerable to race conditions, 
regardless of whether a utility is part of POSIX or not.

--
Raf