|Re: [chrony-users] Chrony malfunction under ARM/Buildroot|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
On Fri, Apr 15, 2016 at 12:55:00AM +0200, Mauro Condarelli wrote:
> Il 14/04/2016 23:03, Bill Unruh ha scritto:
> >That is a driftfile for the rtc. If the rtc is way way out, it has nothing to
> >fix-- ie the fix is nonesense. If your rtc is as flaky as you imply, it might
> >be better not to use the rtc at all. AFAI remember, if there is not rtc (ie
> >the rtcfile directive) chrony will look at a few files, and use the dates from
> >them to set the current time. That will be out (depending on how long th
> >emachine has been off) but it will be in the past, so your concern about the
> >system always going forward will be satisfied.
> If I understand well the "-s" option forces chrony to restart timing from the date of the "driftfile" file (thus providing a monotone, even if wrong, time).
> Did misinterpret the manual?
With the -s option, chronyd will set the system time from the RTC or
the driftfile, depending which one is later. If there is no RTC, it's
just set from the driftfile.
> My current work hypothesis is something bad happens when chronyd tries to update RTC.
> I want to verify this updating RTC with different means (ntpdate).
> It might not be conclusive, but will give me some hint (hopefully).
You can prevent chronyd from touching the RTC (bothing reading and
writing) by setting rtcdevice in the config to a non-existing file.
If that fixes the freeze and crash, it's likely a kernel or HW issue.
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.