Re: [chrony-users] Fwd: Chrony malfunctioning at beaglebones

[ Thread Index | Date Index | More Archives ]

On 10/02/2015 07:32 AM, Miroslav Lichvar wrote:
On Fri, Oct 02, 2015 at 12:13:48PM +0100, Nuno Gonçalves wrote:
On Mon, Sep 7, 2015 at 11:08 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
The -s option will restore the time from the driftfile only if there
is no RTC. If the machine has an RTC, but it's unusable because there
is no battery to keep the time when turned off, you will also need to
tell chronyd to ignore the RTC by setting the rtcdevice to a device
that doesn't not exist. For example:

rtcdevice /dev/nonexist
I see that at Sep 3 your commited a change to this behaviour

Is this supposed to solve this "problem"? It looks it does, but since
your message was after the commit, I am confused how they relate.
That commit fixes a bug that prevented the system time from being
restored from the driftfile when /dev/rtc existed, but reading time
from it failed for some reason. It doesn't fix the problem with not
restoring time from driftfile when the RTC is wrong because there is
no battery.

It would be nice if chronyd detected that automatically, but I'm not
sure what would be the best approach. I was considering to always
check if the system time is 1970-01-01 or 2000-01-01, but someone said
on a different mailing list there are other dates the system clock
would have after initialization from an RTC without battery.

Suggestions are welcome.

Can you read the hardware clock twice, say 1.5 seconds apart, and note if the time has increased? If it hasn't, or if the read fails, it seems pretty certain the hardware clock is busted.

To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject. For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.

Mail converted by MHonArc 2.6.19+