Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured | Date | Fri, 26 Mar 2021 12:13:43 +0100 |
| |
Daphne,
On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=212265
I'm leaving the text from the BZ entry untrimmed so everyone on Cc is on the same page.
> In order for CLOCK_TAI to function properly, a program (usually ntpd) > has to use the adjtimex family of system calls in order to tell the > kernel what the difference is between TAI and UTC. ntpd will do this > as long as it has been configured with a leap seconds file. > > Unfortunately, although the majority of distributions ship with a leap > second file from the zoneinfo database, many or most of them (I have > Arch here) do not configure ntpd to know about it, so ntpd does not > set things up properly for CLOCK_TAI to work. Calling > clock_gettime(CLOCK_TAI, ...) produces the same result as > clock_gettime(CLOCK_REALTIME, ...), yielding UTC instead of the > requested TAI. > > The result is that CLOCK_TAI, which one would usually wish to use to > improve the correctness of a program’s date and time handling, > produces utterly incorrect behaviours on the vast majority of boxes, > unless the system administrator is conscientious enough to configure.
Yes, that's unfortunate, but pretty much historical behaviour and I fear it's not really documented either.
> I would like to suggest that clock_gettime(CLOCK_TAI, ...) and friends > should return an error (EINVAL? ENOTSUP?) when it would return the > same as CLOCK_REALTIME, so that programs can detect when it’s not been > set up correctly and either tell users to go and set up their leap > second data file properly,
That would be a user visible change and might hit existing user space by surprise, so that's not a necessarily a good option.
Of course it could be argued that a given kernel can return -ENOTSUP or whatever is appropriate for any CLOCK id, but that really needs some deep thoughts and analysis vs. eventual disruption.
> or try to improvise TAI on top of UTC using (at the cost of not being > able to be accurate during leap seconds themselves), or both.
The problem with TAI is that the number of leapseconds which need to be accounted for at a given date/time, i.e. when the machine boots, looks simple but leap seconds are not predictable due to the non-linear behaviour of earth rotation.
So we'd need to have an up-to-date leap seconds table:
https://www.ietf.org/timezones/data/leap-seconds.list
which is not rocket science, but there is this little spoilsport in that file:
File expires on: 28 December 2021
and the kernel on it's own has no way to check for and retrieve an up-to-date version. That's why it is delegated to user space.
No idea though why this is not enabled by default in distros when NTP is on. Of course I did not notice because I had that entry in my ntpd/chrony configs forever since we started to hack on it.
> A workaround for programs which want to detect when CLOCK_TAI is wrong is to > try to detect when it hasn't been set up properly by getting both CLOCK_TAI and > CLOCK_REALTIME and falling back to trying to emulate TAI on top of time_t when > the difference between the tv_sec value is ≤ 1 second (not = 0, because it > could happen that the first clock was checked at .00001 seconds before a whole > second and the latter one at .00001 seconds after the whole second). But even > that has edge cases — putting similar logic in the kernel could make it work > correctly all the time.
adjtimex()/ntp_timex() allows you to read out tai_offset race free. Whether that's a good answer is a different question.
My initial takeaway is that at least the documentation sucks.
I hope the NTP/TAI wizards have some more insight/opinions on this.
Thanks,
tglx
| |