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

[Nuno Gonçalves <nunojpg@xxxxxxxxx>]

I didn't tought of the possibility of the RTC being in local time and
having a offline backward change, obviously.

For similiar reasons you have the possibility of the user changing the
timezone under another OS.

I don't think using the compile time is required, and would introduce
a compile dependent behavior, I would prefer to use a magic number.

We could:

- Check for a known wrong date (I would select 2015-01-01 for the
magic number, since there is no advantage of using any other in the
past). If RTC<2015-01-01<driftfile, restore from driftfile.
- Check that the RTC is more in the past than what can be accounted
for DST or Timezone changes. If RTC<driftfile-26h, restore from
driftfile.

I would prefer the second since it avoids using the 2015 magic number,
as we can find in the future RTC defaulting to 2020, for example.

Since I don't see any negative effect, I wouldn't create additional
maintainer complexity with another option.

Thanks,
Nuno

On Mon, Oct 5, 2015 at 10:03 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
> 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.
>

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