coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: Bug#682969: timeout 20 /usr/sbin/ntpd -g -q gives wrong return code
Date: Fri, 27 Jul 2012 19:19:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 07/27/2012 05:56 PM, Jim Meyering wrote:
> Goswin von Brederlow wrote:
>> Package: coreutils
>> Version: 8.13-3.2
>> Severity: normal
>> File: /usr/bin/timeout
>>
>> I'm trying to set the time during boot. Unfortunately ntpd hangs forever
>> if the timeserver is unavailable. So I added a timeout to it so the
>> system still continues to boot without the correct time.
>>
>> But I would like to log the error. Timeout is supposed to return 124 if the
>> time was exceeded. But if ntpd corrects the time by more than the timeout
>> then the return value is 124 despite the fact the real time passed was less.
>>
>> Wouldn't it be possible to detect this case and return the exit code of
>> ntpd instead of a false timeout error?
> 
> Thanks for the report.
> Did you experience an actual problem?
> 
> 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.

Goswin what's the output from uname -a
as a matter of interest?

cheers,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]