suspected bug in timeout command

[Michael Conrad]

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.

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