On Mon, 5 Oct 2015, Miroslav Lichvar 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.
At least on Linux the files should all be labeled in UTC as is the system
clock. Thus DST issues should be irrelevant. It is only the RTC that might
have issues if it is kept in local time. Ie, I would probably trust the file
timestamp more than the RTC in local time. Of course just using the file time
only if it is in the future leaves open the DST change six months later when
the RTC is ahead of the filestamp.
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?
IF someone is keeping their RTC on local time, then I would probably trust the
file more. Of course if the two are out by years (eg the rtc battery is
getting old) then I would definitely trust the timestamp more.
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-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.
