[CAUTION: Non-UBC Email]
Hi Paul,
On Thu, Nov 30, 2023 at 6:38 AM Paul Eggert <eggert@xxxxxxxxxxx> wrote:
The TZDB mailing list has recently been wrestling with the topic of
leap-second table expiration (see [1] and [2] for some of this).
Here's the issue. The leap-seconds.list file, maintained by Judah Levine
of NIST and redistributed by TZDB, contains a line like this:
#@ 3928521600
which in this example specifies an expiration date of 2024-06-28 00:00
UTC. The idea is that this particular leap-seconds.list file should not
be used after the expiration date, after which the file will be obsolete
and pehaps incorrect.
As I understand it, NTPsec parses this comment and rejects obsolete
leap-seconds.list files; this is the traditional ntpd behavior.
Currently Chrony does not look at the leap-seconds.list file. However,
yesterday Patrick Oppenlander proposed[3] a patch to do that.
I only proposed this as the current implementation doesn't work on
musl based systems.
So, three questions:
* If Chrony reads leap-seconds.list should it also look at the leap
second expiration and reject old files?
My initial proposal emits a warning in this case but uses the file
anyway. This is consistent with chrony's existing behaviour (leapsectz
on glibc systems) as it will currently continue to use leap second
information inferred from the time zone without knowing it's expired.
The chrony docs contain a note that the time zone database should be
kept up to date, so it's currently the user's problem to deal with.
* If Chrony does not read leap-seconds.list, but instead uses the
right/UTC file, should it also look at any leap-second expiration
information in that file and reject old files? This would involve Chrony
looking at the file directly instead of relying on localtime/mktime, and
building right/UTC with TZDB's EXPIRES_LINE=1 option.
To me, parsing leap-seconds.list is easier and more direct than
parsing the right/UTC file and calculating the leap second offset,
which is why I proposed the former.
I'm not sure what the best thing to do is if the leap second source is
known to be expired. There's at least three cases to consider:
* The database has expired when chrony starts.
* The database expires while chrony is running, and no leap second has
been announced via NTP after it's expired.
* The database expires while chrony is running, and a leap second has
been announced via NTP after it's expired.
I think in all cases we need to do our best to make sure that there
are no unexpected jumps in the user's clock across a chrony restart.
Theoretically chrony could keep its own history of announced leap
seconds somewhere, but that feels painful and error prone as chrony
may not be running all the time and miss an announcement.
To me, the ideal solution would be for chrony to query a trusted
source on the Internet to get current leap second data and avoid this
whole mess. I'm not aware of such a source though.
Patrick
* If leap seconds are discontinued, which is a distinct possibility,
what sort of "leap second expiration" should Chrony use?
[1]: https://mm.icann.org/pipermail/tz/2023-November/033268.html
[2]: https://mm.icann.org/pipermail/tz/2023-November/033275.html
[3]:
https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-dev/2023/11/msg00013.html
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.