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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Fri, Oct 02, 2015 at 02:13:38PM +0100, Nuno Gonçalves wrote:
> For the typical case, if the user have Chrony installed, does he
> really want to be able to manually adjust the RTC, at least for a big
> backward change?
> 
> If not, why simply not disregard when the RTC "time fails to at least
> have the time restored from the driftfile."?
> 
> I'm copying this from your commit message, that is why I understood
> this would fix it, since I find this behaviour optimal.

You mean to restore time to the modification timestamp of driftfile
when it's in future and the -s option was specified, even when the RTC
device is readable?

It's a possibility, but I'm wondering if it wouldn't be an unexpected
behavior in some cases. Imagine someone finding out the clock is ahead
by one hour after a DST change (RTC is kept in local time because there
is another OS installed on the machine) and there is no network
connectivity to fix it. The user might want to stop chronyd, fix the
system clock or the RTC manually, and start chronyd again or reboot
the machine. The clock would be set to the modification time of the
driftfile, which is still almost one hour ahead and the user wouldn't
know what's happening or how to fix it.

What do we trust more, the RTC, whose purpose is to keep time when the
machine is shut down, or some random file on the filesystem?

I think there are several options:
- leave that decision up to the user, chronyd can be configured to
  ignore the RTC by pointing it to a nonexistent or invalid RTC device
  with the rtcdevice directive. This is not very user or distribution
  friendly.
- always restore time from driftfile with -s if it's in future. Could
  that cause problems in some cases?
- add a new option (-S) to always restore time from driftfile if it's
  in future
- try to detect if the RTC is wrong and ignore it
  - check for the known initial dates (e.g. 1970-01-01, 2000-01-01)
  - check if the time is before some specific date, e.g. chrony
    release date or build date, but can we trust the clock on the
    build machine or assume noone will want to keep clocks in past for
    some testing or other purposes?

Thoughts?

-- 
Miroslav Lichvar

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