Description of problem: After a reboot the time is wrong by a handful of seconds. I don't recall this being an issue in the past. Observed on 5 different f16/x86_64 systems. Version-Release number of selected component (if applicable): chrony.x86_64 1.26-3.20110831gitb088b7.fc16 @fedora kernel.x86_64 3.1.0-7.fc16 @fedora How reproducible: always, but the exact numbers vary. Steps to Reproduce: 1. reboot 2. grep chrony /var/log/messages* | grep seconds Actual results: grep chrony /var/log/messages* | grep seconds /var/log/messages:Nov 11 05:42:09 arbol chronyd[946]: System clock wrong by 0.665578 seconds, adjustment started /var/log/messages-20111023:Oct 19 07:06:05 arbol chronyd[1185]: System clock wrong by 0.674276 seconds, adjustment started /var/log/messages-20111023:Oct 19 07:52:58 arbol chronyd[914]: System clock wrong by 1.016048 seconds, adjustment started /var/log/messages-20111023:Oct 19 08:19:32 arbol chronyd[882]: System clock wrong by 0.572905 seconds, adjustment started /var/log/messages-20111023:Oct 19 08:48:32 arbol chronyd[892]: System clock wrong by -0.640099 seconds, adjustment started /var/log/messages-20111023:Oct 21 03:23:31 arbol chronyd[981]: System clock wrong by 1.810840 seconds, adjustment started /var/log/messages-20111023:Oct 22 03:42:03 arbol chronyd[968]: System clock wrong by 2.847495 seconds, adjustment started /var/log/messages-20111030:Oct 23 03:56:43 arbol chronyd[930]: System clock wrong by 3.752430 seconds, adjustment started /var/log/messages-20111030:Oct 24 03:31:57 arbol chronyd[954]: System clock wrong by 5.375822 seconds, adjustment started /var/log/messages-20111030:Oct 25 04:05:20 arbol chronyd[956]: System clock wrong by 0.902311 seconds, adjustment started /var/log/messages-20111030:Oct 26 14:29:39 arbol chronyd[956]: System clock wrong by 0.533348 seconds, adjustment started /var/log/messages-20111030:Oct 26 14:49:42 arbol chronyd[975]: System clock wrong by 0.979057 seconds, adjustment started /var/log/messages-20111030:Oct 26 14:54:34 arbol chronyd[955]: System clock wrong by 0.952926 seconds, adjustment started /var/log/messages-20111030:Oct 27 13:30:30 arbol chronyd[951]: System clock wrong by 1.370617 seconds, adjustment started /var/log/messages-20111106:Oct 31 03:41:45 arbol chronyd[947]: System clock wrong by 4.914774 seconds, adjustment started /var/log/messages-20111106:Nov 3 03:46:51 arbol chronyd[953]: System clock wrong by 7.876847 seconds, adjustment started /var/log/messages-20111106:Nov 3 13:47:05 arbol chronyd[951]: System clock wrong by 8.154237 seconds, adjustment started /var/log/messages-20111106:Nov 5 15:06:50 arbol chronyd[969]: System clock wrong by 9.893666 seconds, adjustment started Expected results: Something that is off by <1 second at most with an RTC that has 1 second granularity. Additional info: The same thing is observed on all my F16 systems (5 of them). This is not an isolated machine with a troublesome RTC. I have no idea if this is chronyd not doing a proper rtcsync or some other problem with the RTC not being read correctly by the kernel. It is disconcerting to see large numbers like this on every boot. 4 out of 5 of the machines have stock /etc/chrony.conf files. The other one is stock with a few additions. In all cases the files have the "rtcsync" directive.
The rtcsync directive just clears the adjtimex UNSYNC status flag which enables the 11-minute kernel mode, similarly to what ntpd does. I can confirm that it doesn't seem to be working well with kernel 3.1.1-1.fc16.x86_64, after an hour after boot I can still see a 2 second offset between RTC and synchronized local clock. Probably the reason why it wasn't visible before is that hwclock --systohc used be called on every shutdown, but it's not anymore. (see bug #750883) Reassigning to kernel.
As a work-around for anyone else seeing this problem, I have turned off rtcsync in /etc/chrony.conf and added an hourly hwclock sync. That had two effects. 1) /etc/adjtime finally got updated from the distributed version. 2) the boot-up messages about the clock being off have disappeared. /etc/cron.hourly/hwclock: #!/bin/sh # # WSRCC: periodically update the hwclock. Something is broken in # chrony and/or the kernel when using chrony's rtcsync. # hwclock --systoh # # end #
Seeing the same problem. I have a RTC that is out by a couple of hours. Everything on the server is configured for UTC. rtcsync is enabled. rtconutc is also enabled. rtcsync never happens. Restarting chronyd causes the system clock to be reset to the (very wrong) RTC time until there is data from the NTP server again.
(In reply to comment #3) > Seeing the same problem. I have a RTC that is out by a couple of hours. > Everything on the server is configured for UTC. rtcsync is enabled. rtconutc is > also enabled. If the error is a whole number of hours, you might be hitting bug #753642. This bug report is about the kernel RTC synchronization (11 minute mode) which only sets minutes and hours.
(In reply to comment #4) > This bug report is about the kernel RTC synchronization (11 minute mode) which > only sets minutes and hours. That should be minutes and seconds. Kernel doesn't know about timezones so it sets the clock only within +-15 minutes.
I am also seeing this, also using chrony on Fedora 16. $ cat /sys/class/rtc/rtc0/time ; date -u ; uptime 18:40:46 Sáb Fev 11 18:41:53 UTC 2012 16:41:53 up 6:14, 10 users, load average: 0.01, 0.05, 0.10 This laptop has been powered on for 6 hours, more than enough for the kernel to correct the RTC. The kernel seems to think it is synchronized: $ ntptime ntp_gettime() returns code 0 (OK) time d2e1352b.99d4a5a8 Sat, Feb 11 2012 16:42:51.600, (.600901699), maximum error 202000 us, estimated error 16000000 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency 10.242 ppm, interval 1 s, maximum error 202000 us, estimated error 16000000 us, status 0x2081 (PLL,FREQHOLD,NANO), time constant 0, precision 0.001 us, tolerance 500 ppm, (I do not have ntp installed, I extracted the ntptime executable from ntp-4.2.6p4-1.fc16.x86_64.rpm) I see no set_rtc_mmss error messages on dmesg: $ dmesg | fgrep -i rtc [ 0.419218] RTC time: 12:27:25, date: 02/11/12 [ 1.056988] rtc_cmos 00:06: RTC can wake from S4 [ 1.057120] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 [ 1.057152] rtc0: alarms up to one month, y3k, 242 bytes nvram, hpet irqs [ 1.067585] rtc_cmos 00:06: setting system clock to 2012-02-11 12:27:26 UTC (1328963246) For some reason, the kernel is not updating the RTC time, even though as far as I can see it should. The relevant config variable (CONFIG_GENERIC_CMOS_UPDATE) is set in the kernel configuration, and rtcsync is set on /etc/chrony.conf (in fact, it is the default chrony.conf). The relevant packages are: chrony-1.26-3.20110831gitb088b7.fc16.x86_64 kernel-3.2.3-2.fc16.x86_64
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
It will take a week or two to be sure, but a 24hr instrumentation of the hwclock with a "hwclock -r" every hour shows the hwclock to be hovering within a second of the correct time. It may well be fixed. I'll update again in a ~1 week. Mar 26 01:01:02 arbol hwclock: Mon Mar 26 01:01:03 2012 -0.876943 seconds Mar 26 02:01:01 arbol hwclock: Mon Mar 26 02:01:02 2012 -0.033160 seconds Mar 26 03:01:02 arbol hwclock: Mon Mar 26 03:01:03 2012 -0.861313 seconds Mar 26 04:01:02 arbol hwclock: Mon Mar 26 04:01:03 2012 -0.611324 seconds Mar 26 05:01:02 arbol hwclock: Mon Mar 26 05:01:03 2012 -0.829927 seconds Mar 26 06:01:02 arbol hwclock: Mon Mar 26 06:01:03 2012 -0.860441 seconds Mar 26 07:01:02 arbol hwclock: Mon Mar 26 07:01:03 2012 -0.830073 seconds Mar 26 08:01:02 arbol hwclock: Mon Mar 26 08:01:03 2012 -0.720684 seconds Mar 26 09:01:02 arbol hwclock: Mon Mar 26 09:01:03 2012 -0.767542 seconds Mar 26 10:01:02 arbol hwclock: Mon Mar 26 10:01:02 2012 -0.205093 seconds Mar 26 11:01:02 arbol hwclock: Mon Mar 26 11:01:02 2012 -0.830027 seconds Mar 26 12:01:02 arbol hwclock: Mon Mar 26 12:01:02 2012 -0.673220 seconds Mar 26 13:01:02 arbol hwclock: Mon Mar 26 13:01:02 2012 -0.830059 seconds Mar 26 14:01:02 arbol hwclock: Mon Mar 26 14:01:02 2012 -0.860546 seconds Mar 26 15:01:02 arbol hwclock: Mon Mar 26 15:01:02 2012 -0.830037 seconds Mar 26 16:01:02 arbol hwclock: Mon Mar 26 16:01:02 2012 -0.736267 seconds Mar 26 17:01:02 arbol hwclock: Mon Mar 26 17:01:02 2012 -0.798817 seconds Mar 26 18:01:02 arbol hwclock: Mon Mar 26 18:01:02 2012 -0.830054 seconds Mar 26 19:01:02 arbol hwclock: Mon Mar 26 19:01:02 2012 -0.783196 seconds Mar 26 20:01:02 arbol hwclock: Mon Mar 26 20:01:02 2012 -0.860432 seconds Mar 26 21:01:02 arbol hwclock: Mon Mar 26 21:01:02 2012 -0.845450 seconds Mar 26 22:01:02 arbol hwclock: Mon Mar 26 22:01:02 2012 -0.783178 seconds Mar 26 23:01:02 arbol hwclock: Mon Mar 26 23:01:02 2012 -0.798618 seconds Mar 27 00:01:02 arbol hwclock: Tue Mar 27 00:01:03 2012 -0.844763 seconds Mar 27 01:01:02 arbol hwclock: Tue Mar 27 01:01:03 2012 -0.736263 seconds
Created attachment 581736 [details] hwclock offsets and chrony gripes It isn't clear why the hw clock reports good time while the computer is running but after a reboot chrony sometimes claims the time is off by over 1 second. We aren't talking about long reboots either. The computer is only down for a minute or two.
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
It looks like this may still not be fixed yet. A similar report is in bug #985522.