http://bugzilla.opensuse.org/show_bug.cgi?id=936265 Bug ID: 936265 Summary: create a global configuration for hwclock Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: sbrabec@suse.com Reporter: sbrabec@suse.com QA Contact: qa-bugs@suse.de CC: max@suse.com, werner@suse.com Found By: --- Blocker: --- There are several sources of hwclock adjustment: - NTP - kernel 11 minutes sync - hwclock --adjust - shutdown and suspend quirks Some of these adjustments are conflicting. For example hwclock --adjust expects that no other utility adjusts hwclock. If it does, and bad thinks happen, we can experience very ugly drifts (see bug 871698 (internal) for an example of
20 years drift per day, http://www.spinics.net/lists/util-linux-ng/msg09294.html).
Some systems have good system clock and bad hwclock. Other have good hwclock and inaccurate system clock. Some of them sync over NTP. => There is not a single configuration that fits to all, and there is a good chance to make things worse with a bad configuration. The discussion in the bug 925873 comment 72 and bug 925873 comment 81, the logic should be following: - --systohc on suspend/shutdown makes sense for systems with bad hwclock. But adjtime must be disabled then. - no explicit adjustment makes sense if ntp service is running and the kernel stays in elven minutes mode (bit 64 in the status line return by adjtimex is *not* set -> STA_UNSYNC[1]). hwclock drift andjustment MUST be off, otherwise bad things will happen. - --systohc on suspend/shutdown makes sense on systems with NTP, where elven minutes sync mode is off (bit 64 in the status line return by adjtimex is *set* -> STA_UNSYNC[1]). hwclock drift andjustment can be on, as long as we are sure that hwclock is the only utility that sets the time. - regular --hctosys and regular --adjust makes sense for systems with bad system clock. But systohc on suspend/shutdown must be disabled then. With FATE 316730 (internal https://fate.novell.com/316730), the matrix could be even more complex because DST adjustment could be conde in several ways. I guess we should create global sysconfig for them: something like: 1) Best offline clock source: Here are proposed texts for possibilities: Prefer hardware clock over system clock. If no source of accurate time (e. g. NTP) is available, never update hardware clock automatically. Also attempt to apply regular sync from hardware clock to system. If accurate time (e. g. NTP or explicit user adjustment) is available, attempt to compute hardware clock drift and adjust them. Prefer system clock over hardware clock. If no source of accurate time (e. g. NTP) is available, trust the system time. Read from hardware clock only if it is required (e. g. on boot). Regularly adjust hardware clock from the system clock. - Here can be two sub-possibilities: compute or not compute hardware clock drift 2) hwclock time zone In future, system can follow EFI BIOS time zone, or use preconfigured time zone. Or time zone is not available in BIOS, and preconfigured time zone will be used. 3) DST In future, system can follow EFI BIOS DST setting. Note: We will need to port /usr/lib/pm-utils/sleep.d/90clock to systemd and improve it to make adjustments depending on this sysconfig not only on shutdown, but also during hibernation. -- You are receiving this mail because: You are on the CC list for the bug.