Arch Linux

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)?

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.

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?

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).

Looks like this fix will also work well with RTC in localtime: http://fpaste.org/N0wc/ . I'll leave it up to Thomas and Tobias if we should apply it or wait.

Tom, the paste you linked has expired.

Apart from that, I'd still like to point out that using localtime is broken by design.

@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.

I guess this can be closed, right?

@djgera: it has not been fixed as far as I know, but also nothing we are likely to do anything about.