Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#27408 - [linux] rtc is not corrected if more than 15 minutes off

Attached to Project: Arch Linux
Opened by Dan McGee (toofishes) - Friday, 02 December 2011, 15:49 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 30 July 2013, 10:44 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


Every time I boot my home computer, the clock is off by an hour.

We need to sync the hwclock on shutdown, no ifs/ands/buts, if we are using it on startup.

ntpd does not sync this, ever, contrary to what the bogus comment implies in rc.conf.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 30 July 2013, 10:44 GMT
Reason for closing:  Won't fix
Comment by Tom Gundersen (tomegun) - Friday, 02 December 2011, 23:48 GMT
Before I look any deeper into this (could not immediately reproduce), what is the value of your HARDWARECLOCK variable in rc.conf, what is the contents of /var/lib/hwclock/adjtime, is /var on a separate partition, and what NTP daemon are you using?

Would you care to explain a bit more why you think the comment is bogus? Have you verified that 11-minute-mode is not enabled in your kernel when ntp is running? If it is not, what makes you think this is not a bug (a link to discussion/documentation would be great)?
Comment by Tom Gundersen (tomegun) - Thursday, 29 December 2011, 14:32 GMT
juergbi and kay from #systemd helped me with some more info on this issue. This is the situation:

We should never set rtc from system time, unless we are certain that system time is correct. There are two ways the rtc could be set: manually by calling hwclock if you happen to know what time it is; or let the kernel know that system time is correct and it will make sure to update the rtc from time to time (11-minutes-mode).

When using an ntp server the latter is done. This can be verified by checking the kernel's time status bit 0x40 / STA_UNSYNC, which should be unset if an ntp server is being used. As far as I know this works well with ntpd.

There is a caveat here, the kernel will never update the rtc if it is more than 30 minutes wrong. This might have made sense when we still cared about working around rtc being in localtime, but nowadays it does not make any sense at all.

To fix this issue ntpd should either be made to set rtc by force, or the kernel should be patched to ignore the 30-min limit.

A workaround should be (please confirm) to set rtc manually using hwclock (to something which is less than 30 minutes wrong) and then wait for the 11-minutes-mode to kick in and set the proper time.
Comment by Dan McGee (toofishes) - Thursday, 29 December 2011, 15:06 GMT
Sorry I never got back to you on this, the holidays have been busy and I haven't been rebooting a whole lot.

The final workaround seems to work- I haven't seen a mismatched local call since I explicitly called hwclock and set the time. Does this get confused by localtime/UTC or what is the status with that?
Comment by Tom Gundersen (tomegun) - Thursday, 29 December 2011, 15:43 GMT
No problem. Good to know it worked!

The kernel's rtc handling has no clue about localtime (as far as I can tell), so there is no way this could work seamlessly with RTC in localtime.

The way it works now is that if your RTC is in localtime the kernel will never touch it (I guess the 30-min limit is meant as a test for RTC being in localtime). The assumption being that a secondary OS is in use which will take care of the clock.

We have sort of given up on supporting localtime, but we try to at least stay out of the way if the user wants to use it (it should work fine if you are willing and able to adjust the clock manually from time to time).
Comment by Tom Gundersen (tomegun) - Thursday, 29 December 2011, 21:55 GMT
Looks like this fix will also work well with RTC in localtime: . I'll leave it up to Thomas and Tobias if we should apply it or wait.
Comment by Thomas Bächler (brain0) - Friday, 30 December 2011, 13:11 GMT
Tom, the paste you linked has expired.

Apart from that, I'd still like to point out that using localtime is broken by design.
Comment by Tom Gundersen (tomegun) - Friday, 30 December 2011, 13:19 GMT
@Thomas: damn, should have attached it. As to localtime, you are preaching to the choir, the patch is equally valid for RTC in UTC or localtime, in either case it will fix the case where the RTC is more than 15 minutes off.

I hope it will be posted to LKML, I'll keep an eye on it.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 30 January 2013, 16:09 GMT
I guess this can be closed, right?
Comment by Tom Gundersen (tomegun) - Wednesday, 30 January 2013, 16:22 GMT
@djgera: it has not been fixed as far as I know, but also nothing we are likely to do anything about.