| Summary: | time not correct after reboot | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wolfgang Rupprecht <wolfgang.rupprecht> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | cesarb, fullung, gansalmon, hongjiu.lu, igeorgex, itamar, jeremy, jonathan, kernel-maint, madhu.chinakonda, mlichvar, mschmidt, roger.k.wells, stephent98 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-13 15:34:34 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Wolfgang Rupprecht
2011-11-12 22:19:36 UTC
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. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [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. |