[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.