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 <mlich...@redhat.com> 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
http://git.tuxfamily.org/chrony/chrony.git/commit/?id=7d6de7afe680bababef4421250c7af62d643aa14
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-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
