https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c1 Stefan Seyfried changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ro@novell.com --- Comment #1 from Stefan Seyfried 2011-06-10 23:08:29 CEST --- adding aaa_base maintainer to CC Note that I see similar problems with SLES11 SP1, will open a Service Request for that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c2 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Dr. Werner Fink 2011-06-14 07:41:37 UTC --- INVALID as ntpd force eleven minute mode (read manual page adjtimex(8)) that is if the kernel is in eleven minute mode the hardware clock is synchronized every eleven minutes with the system clock. Please not this will not be changed as it is correct. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c4 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #4 from Dr. Werner Fink 2011-06-14 08:13:31 UTC --- Changelog of aaa:base of SLES11-SP1-UPDATE: Tue Dec 21 17:21:56 CET 2010 - Do not remove /etc/adjtime (bnc#650719) but correct the third line - Test only for bit 64 (clock unsynchronized), if zero the kernel is within eleven minutes mode (Thanks goes to Rastislav David) Update your system -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c6 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |seife@novell.slipkontur.de --- Comment #6 from Dr. Werner Fink 2011-06-14 09:42:45 UTC --- It works ... you have to wait upto the point where the kernel does not do the eleven minute mode anymore. It is not supported to destroy the sync between the hardware clock any the kernel system time as the hardware clock is under the control of the kernel its self. Now the status bits 24577 shows: Enabled PLL updates (is read/write) Resolution in nano seconds (readonly) Frequency-lock mode active (readonly) now the status bits 8193 Enabled PLL updates (is read/write) Resolution in nano seconds (readonly) that's it (-> /usr/include/sys/timex.h part ``Status codes''). Now explain what is wrong with this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c8 Stefan Seyfried changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|seife@novell.slipkontur.de | --- Comment #8 from Stefan Seyfried 2011-06-14 13:39:40 CEST --- There is nothing wrong with the bits - just the kernel does not sync the CMOS clock. I did the following: * set the cmos clock wrong (to 09:00) * reboot on boot: Jun 14 09:01:45 nw8000 sntp[3655]: Started sntp Jun 14 12:48:22 nw8000 ntpd[3664]: ntpd 4.2.6p3@1.2290-o Wed Feb 23 00:32:28 UTC 2011 (1) Jun 14 12:48:22 nw8000 ntpd[3665]: proto: precision = 1.396 usec So far, so good. Now: nw8000:~ # adjtimex --print|grep status status: 8193 nw8000:~ # uptime 13:11 up 0:23, 3 users, load average: 0,16, 0,05, 0,09 nw8000:~ # date;hwclock Di 14. Jun 13:11:24 CEST 2011 Di 14 Jun 2011 09:11:25 CEST -1.015618 seconds So it looks like only the minutes are actually synchronized. There is actually a comment in the kernel source arch/x86/kernel/rtc.c: 41 int mach_set_rtc_mmss(unsigned long nowtime) 42 { .. 59 /* 60 * since we're only adjusting minutes and seconds, 61 * don't interfere with hour overflow. This avoids 62 * messing with unknown time zones but requires your 63 * RTC not to be off by more than 15 minutes 64 */ 65 real_seconds = nowtime % 60; 66 real_minutes = nowtime / 60; 67 /* correct for half hour time zone */ 68 if (((abs(real_minutes - cmos_minutes) + 15)/30) & 1) 69 real_minutes += 30; 70 real_minutes %= 60; 71 72 if (abs(real_minutes - cmos_minutes) < 30) { 73 if (!(save_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) { 74 real_seconds = bin2bcd(real_seconds); 75 real_minutes = bin2bcd(real_minutes); 76 } 77 CMOS_WRITE(real_seconds, RTC_SECONDS); 78 CMOS_WRITE(real_minutes, RTC_MINUTES); 79 } else { 80 printk_once(KERN_NOTICE 81 "set_rtc_mmss: can't update from %d to %d\n", 82 cmos_minutes, real_minutes); 83 retval = -1; 84 } so assuming "kernel is in eleven-minute-mode => CMOS clock is set correctly" is wrong. We should set the cmos clock on shutdown, even if the kernel is in eleven-minute-mode IMHO -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c10 --- Comment #10 from Stefan Seyfried 2011-06-14 14:24:12 CEST --- Yes, my customer is buying systems in lots of 100 servers, and they all come with pretty random dates set. Certainly several hours off (because they are either set to american or taiwanese localtime). The same is true after exchanging broken hardware: a machine that had correct time before the replacement has random time after. And it never gets corrected. At the customer, we simply solved it with a cron job that runs "hwclock --systohc --noadjfile --utc" once per day. But I still think that during shutdown of the system, we have all needed information to set the hwclock correctly: * we know if it is set to UTC or LOCAL * we know if the system time is correct (NTP configured) So we should be able to make an informed decision to set the clock correctly, which the kernel cannot make due to the timezone problem. For my machines at home I'm now working around this with a line readonly ELEVENMIN_MODE=no in /etc/sysconfig/clock, but I don't think that's something to recommend ;) The very least we need to do IMHO is document in /etc/sysconfig/clock that SYSTOHC="yes" does not mean "write time to hwclock on shutdown" but actually in real systems with NTP means "never write time to hwclock, no matter what you are doing". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c12 Robert Davies changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rob.opensuse.linux@googlema | |il.com --- Comment #12 from Robert Davies 2011-07-10 23:48:08 UTC --- In old versions of NTP, you were expected to STEP the clock first on boot for large discrepancies, and only then slew the time after by cron job, or running NTP daemon. It was no good having many unstable peers & servers. It seems like bar bugs that this need was already accounted for. In /etc/init.d/ntp : start) if [ "$NTPD_FORCE_SYNC_ON_STARTUP" = "yes" ]; then # get the initial date from the timeservers configured in ntp.conf ntpd_is_running || $0 ntptimeset fi And : ntptimeset) NTPD_PROTO="$( get_ntpd_ip_proto )" for i in $(gawk '/^server/ { if( $2 !~ "^127.127." ) print $2","$3 }' $NTP_CONF) do <snip> sntp -t 2 -l /dev/null -s $SNTP_OPT 2> /dev/null && { SYNCHRONISED=$SNTP_OPT; break; }; done if [ "$SYNCHRONISED" ] then echo "Time synchronized with $SYNCHRONISED" else echo "Time could not be synchronized" fi ;; So perhaps simply making the initial & any following daemon starts, where synchronisation has not succeeded with 24 hours, would solve this issue? Adding code, roughly like : if [ "$SYNCHRONISED" ] then echo "Time synchronized with $SYNCHRONISED" touch /var/lib/ntp/ntp-synchronised-start # record synchronisation time else On "ntp start": # test for recent synchronisation test `find /tmp/ntp -name ntp-synchronised-start -mtime -1 -print` || NTPD_FORCE_SYNC_ON_STARTUP=yes if [ "$NTPD_FORCE_SYNC_ON_STARTUP" = "yes" ]; then # get the initial date from the timeservers configured in ntp.conf ntpd_is_running || $0 ntptimeset -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c14 --- Comment #14 from Robert Davies 2011-07-11 14:40:52 UTC --- (In reply to comment #11)

Normally the CMOS clock is set only once to UTC and all works flawless. Setting the CMOS clock to localtime is a user error (and IMHO we should not support this anymore as Windows7[tm] can handle UTC im CMOS).

For broken hardware you loose as there is no chance to correct anything.

I tested Windows 7 running with UTC, as it is my preference. The problem is it is not acceptable to users, because the time shown "localtime" is then UTC, with additional clock in true localtime. Setting Windows local time clock to Europe/London GMT/BST wiith DST and "additional clock" to be UTC, causes the out by an hour problem!! MS HAVE not properly supported, system clock in UTC BUT insist in doing DST, and non DST adjustment means it's not localtime. sntp -s on boot, did indeed fix up the Linux clock, as well as CMOS clock and allow NTP to operate & synchronise from there on. No 11 minute mode, if it's done before the NTP daemon is even started. Frankly I cannot see why, an "sntp -s" with 2 or 3 defined servers, is not simply done on boot anyway, the CMOS clock is not nearly as accurate as NTP protocol. Doing that EVERY time simplifies the rcntp script to. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c16 --- Comment #16 from Robert Davies 2011-07-11 15:06:48 UTC --- Very true, so in that case you don't define an NTP server externally, but use local time sources. :) 1000 server installation, 100 new machines on dial up, fine. Set 1 Master, 2 stratum 2's, then stratum 3's which broadcast the NTP time in local nets. Then that end user defines an "sntp -j" when the net link comes up to slew the clock, set initially by "sntp -s". In actual fact what tends to matter, is that the clocks agree, not that they're accurate to the second. If a dial up user complains having set external time servers, it's a configuration error; they are asking for those servers to be queried, by the server. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c18 --- Comment #18 from Robert Davies 2011-07-11 19:54:39 UTC --- The CMOS clock should be set correctly before the NTP daemon is started. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c20 --- Comment #20 from Robert Davies 2011-07-13 15:53:23 UTC --- Because in the bug description, Stefan correctly points out that ntpd, is not setting the clock to the actual time, which is what the end user expects. Werner saying (also IMO correctly), that NTP daemon behaviour should not be changed. sntps -s sets system time and for hour off, the RTC/CMOS clock appears to get set right. The issues I had, were IMO Windows bugs, where NTP synchronisation is set, yet they adjust the clock, causing issue on reboot to Linux. Setting clock wildly out, it shows it corrected for by -12925 seconds, now I have : fir:~ # date Wed Jul 13 16:43:43 BST 2011 fir:~ # hwclock Wed Jul 13 20:13:48 2011 -0.234731 seconds fir:~ # echo peers |ntpdc peers remote local st poll reach delay offset disp ======================================================================= =glfd-dmzutil-1. 82.26.243.130 2 64 177 0.01375 -0.000040 0.07019 =LOCAL(0) 127.0.0.1 10 64 160 0.00000 0.000000 1.39331 =winn-dmzutil-1. 82.26.243.130 2 64 177 0.01601 0.000648 0.06609 =dns1.rmplc.co.u 82.26.243.130 2 64 177 0.01511 -0.001409 0.06371 =utserv.mcc.ac.u 82.26.243.130 2 64 177 0.01910 0.003854 0.07028 *d.st1.ntp.br 82.26.243.130 1 64 177 0.24388 0.016828 0.05862 In /etc/init.d/ntp BEFORE ntpd is started, after system time is set by sntp -s, one can hwclock -w --noadjfile to make the CMOS clock, roughly correct. That then lets NTP & kernel 11 minute mode correct for systematic drift as designed. As we know & Windows can also these days synchronise to NTP time correctly, then the solution to this bug, is simple. Set system time, write to hwclock, when booting up NTP. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c29 --- Comment #29 from Jiří Suchomel 2011-10-06 14:05:01 UTC --- Currently, YaST starts reading system clock (with 'date') and on saving, it writes HW clock (hwclock --set) and synchronizes it back with system one (hwclock --hctosys). So it actually should get corrected anyway, right? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c31 --- Comment #31 from Jochen Roeder 2011-10-06 14:35:28 UTC --- (In reply to comment #30) ok. So we have verified that the problem is only existent in image based installation workflows. If one add these steps to the post install script the issue will not arise until he has a hardware problem. That should be sufficient. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c35 Jiří Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|ro@suse.com |jro@novell.com --- Comment #35 from Jiří Suchomel 2011-11-22 13:26:23 UTC --- No idea. Jochen? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c37 Jiří Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #37 from Jiří Suchomel 2011-11-22 16:29:13 UTC --- So I assume the original report is actually not a bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c39 --- Comment #39 from Stefan Seyfried 2011-12-23 09:56:00 CET --- Archie, you are missing nothing IMVHO ;-) I have explained how I work around the issue in http://seife.kernalert.de/blog/2011/12/23/if-you-dont-want-to-fight-package-... executive summary: put readonly ELEVENMIN_MODE=no into /etc/sysconfig/clock. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c41 --- Comment #41 from Dr. Werner Fink 2011-12-23 09:46:45 UTC --- E.g. for more information see `man 8 hwclock' at section: Automatic Hardware Clock Synchronization By the Kernel [...] If your system runs with 11 minute mode on, don't use hwclock --adjust or hwclock --hctosys. You'll just make a mess. It is acceptable to use a hwclock --hctosys at startup time to get a reasonable System Time until your system is able to set the System Time from the external source and start 11 minute mode. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c43 --- Comment #43 from Archie Cobbs 2011-12-23 19:54:57 UTC --- (In reply to comment #42)

In bash code the point b) could look like ...

Yes, option (b) makes the most sense to me as well. Can we get that added? Does somebody need to create a new feature request? Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c45 Andrew Chace changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chacea@fullcount.net --- Comment #45 from Andrew Chace 2012-03-27 15:49:02 UTC --- This is a problem for us as well. To work around it, we've added commands to "halt.local" to explicitly set the hardware clock to system time (--systohc) each time the system is shut down. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=699400 https://bugzilla.novell.com/show_bug.cgi?id=699400#c47 --- Comment #47 from Archie Cobbs 2012-03-27 16:08:27 UTC --- FYI, Since this bug is marked resolved/invalid, and nobody answered my question in comment #43, I went ahead and filed a feature request as Bug #754329. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.