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