Re: Bug#682969: timeout 20 /usr/sbin/ntpd -g -q gives wrong return code

[Jim Meyering]

Pádraig Brady wrote:
> On 07/27/2012 05:56 PM, Jim Meyering wrote:
...
>> When I try to trigger such misbehavior, timeout seems to work fine
>> on a system (Fedora 17) with a working timer_settime function:
>>
>>     $ timeout 2 date --set=$(LC_ALL=C date -d 10\ sec +@%s); echo $?
>>     0
>>
>> I.e., when timeout's child terminates, the clock says
>> 10 seconds have elapsed, yet it exits 0, because the
>> duration was less than 2 seconds.
>>
>> I'm using the timeout from coreutils-8.17, but nothing
>> has changed in this area since before 8.13.
>>
>> I even rebuilt my timeout binary, simulating no timer_settime
>> function so that it would take the alarm-using path.  Same result.
>
> Note timeout(1) currently uses timer_create(CLOCK_REALTIME).
> That could jump and cause signals to fire.
> Though I can't reproduce here, even when pushing the
> updated system clock down to the hardware:
>
> # timeout 3 sh -c 'date --set=$(LC_ALL=C date -d 10\ sec +@%s);
> hwclock -w; sleep 1'
> # echo $?
> 0
>
> I was wondering about using CLOCK_MONOTONIC instead,
> though I'd need to test how that functions over a suspend/resume.
> I suspect it only counts up while the system is running.
> Maybe we should default to system running time, rather than
> wall clock time, though then we'd have to look at/document
> the inconsistency on systems without CLOCK_MONOTONIC.

Yes, using CLOCK_MONOTONIC looked tempting to me, too, but finding
no problem with the use of CLOCK_REALTIME, I was leery of switching.