Hi, As we (hopefully) all know on 30th of June we'll observe leap second. tzdata information was updated in release 2015a in January. This version was imported in FreeBSD HEAD (r279706), 10-STABLE (r279707), 9-STABLE (r279708) and 8-STABLE (r279709) on 6th of March. Since then there were no releases and therefore users of _supported_ releases don't have tzdata information about incoming leap second. RedHat published a very detailed guide about that: https://access.redhat.com/articles/15145. I believe that FreeBSD Project should issue Errata Notices for all supported version with update to share/zoneinfo/leap-seconds.list file. This also means update to 8.4-R that will be supported till the last (and leap) second of 30th of June. Pawel. -- One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
On 2015-Jun-23 20:03:35 +0100, Pawel Biernacki <pawel.biernacki at gmail.com> wrote:>As we (hopefully) all know on 30th of June we'll observe leap second. > tzdata information was updated in release 2015a in January....>I believe that FreeBSD Project should issue Errata Notices for all >supported version with update to share/zoneinfo/leap-seconds.list file.None of my FreeBSD systems have a share/zoneinfo/leap-seconds.list file. Why should the Project issue an EN for a non-existent file? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20150624/68642d17/attachment.sig>
On Tue, Jun 23, 2015, at 14:03, Pawel Biernacki wrote:> Hi, > > As we (hopefully) all know on 30th of June we'll observe leap second. > tzdata information was updated in release 2015a in January. This > version > was imported in FreeBSD HEAD (r279706), 10-STABLE (r279707), 9-STABLE > (r279708) and 8-STABLE (r279709) on 6th of March. Since then there were > no > releases and therefore users of _supported_ releases don't have tzdata > information about incoming leap second. > RedHat published a very detailed guide about that: > https://access.redhat.com/articles/15145. > I believe that FreeBSD Project should issue Errata Notices for all > supported version with update to share/zoneinfo/leap-seconds.list file. > This also means update to 8.4-R that will be supported till the last (and > leap) second of 30th of June. >I'm not an expert on the leapsecond operation, but if I understand it correctly there are two ways a system can be notified of a leapsecond: via a tzdata update or through NTP. I *think* if the tzdata was missing the leapsecond information but the server was syncing to an NTP server that is aware of the leapsecond, the leapsecond info is passed to the NTP client ~24 hours before it happens. This would mean there are three potential scenarios: 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not synced to NTP ends up 1 second off 2) FreeBSD server unaware of leapsecond due to no tzdata entry synced to leapsecond-aware NTP server successfully handles leapsecond 3) FreeBSD server unaware of leapsecond due to no tzdata entry acting as NTP server doesn't notify clients of leapsecond and they end up 1 second off Can anyone confirm/deny if this summary is accurate?
Mark Felder <feld at FreeBSD.org> writes:> I'm not an expert on the leapsecond operation, but if I understand it > correctly there are two ways a system can be notified of a leapsecond: > via a tzdata update or through NTP.Answering a bit late, but no: in practical terms, only NTP works. Recording leap seconds in tzdata breaks POSIX and a lot of assumptions in existing code, not only on the day a leap second occurs but at any time in history after at least one leap second has occurred.> 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not > synced to NTP ends up 1 second offA server which is not synchronized with a reliable external source will end up a lot more than one second off regardless of leap seconds, because it relies solely on onboard RTCs and oscillators which are both inaccurate and imprecise. Clock drift will be measured in seconds per week and vary depending on CPU load, disk I/O, the phase of the moon and your dog's horoscope.> 2) FreeBSD server unaware of leapsecond due to no tzdata entry synced to > leapsecond-aware NTP server successfully handles leapsecondCorrect.> 3) FreeBSD server unaware of leapsecond due to no tzdata entry acting as > NTP server doesn't notify clients of leapsecond and they end up 1 second > offThis assumes that the hypothetical server is not synchronized with a reliable external source, which is a broken setup to begin with (see 1). DES -- Dag-Erling Sm?rgrav - des at des.no