Solved Leapseconds file expired

Well, I don't know about the way it's supposed to work... but my system doesn't seem to update any leap-seconds files. And the fetch command, when run manually, seems to accomplish nothing:
Dec 13 09:18:01 notebook2 ntpd[695]: leapsecond file ('/etc/ntp/leap-seconds'): expired less than 351 days ago
 
No, waiting for the major upgrade to 12.0 !!! No time for that yet. :)
OK, updated everything now to FreeBSD-12.0-p7. Still didn't work until I added the following to my /etc/rc.conf (according to /etc/defautls/rc.conf):
Code:
ntp_leapfile_sources="https://www.ietf.org/timezones/data/leap-seconds.list"
ntp_leapfile_fetch_opts="-mq"
ntp_leapfile_expiry_days=30
ntp_leapfile_fetch_verbose="YES"
 
A client ran into the following error while the machine was correctly functioning.

Code:
freebsd nptd[12345]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired 122 days ago

At first we tried fixing this with:

service ntpd onefetch

After checking further we noticed the client removed the package ca_root_nss.

pkg install ca_root_nss && service ntpd onefetch

Still ran into an error which seemed that the DNS resolving failed. Our client removed the nameserver from /etc/resolv.conf too.
After resolving this running the onefetch again fixed all issues.
 
A client ran into the following error
Dear Marius,

as client's stupidities know no limits, please spare us with stories like that.

The FreeBSD forums is not meant to document all kind of failures and possibilities in the real world. A lot of people read postings here and do not want to lavish their lifetime of problems any newbie could solve.

Instead use this forum when YOU need help. Please!

For client-fun-storied we have the Off-Topic-Forum, where things go like "client got strangulated with wireless mouse cable".

Disclaimer: Not meant to be personally offensive.
 
  • Thanks
Reactions: a6h
A client ran into the following error while the machine was correctly functioning.
Also had a client with this error, still running 13.1-RELEASE-p6. As of 2023-11-23, this website (https://www.ietf.org/timezones/data/leap-seconds.list) says:
ietf.org is no longer serving this file.
Apparently it's a current known issue: https://wiki.linuxfromscratch.org/blfs/ticket/18738

Here's a quick workaround:

Code:
cd /var/db/
mv ntpd.leap-seconds.list ntpd.leap-seconds.list_backup
fetch https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
mv leap-seconds.list ntpd.leap-seconds.list
chmod 644 ntpd.leap-seconds.list
 

2. Default Leap Second Handling on FreeBSD​

The easiest way to handle leap seconds is with the POSIX time rules FreeBSD uses by default, combined with NTP. When ntpd(8) is running and the time is synchronized with upstream NTP servers that handle leap seconds correctly, the leap second will cause the system time to automatically repeat the last second of the day. No other adjustments are necessary.
If the upstream NTP servers do not handle leap seconds correctly, ntpd(8) will step the time by one second after the errant upstream server has noticed and stepped itself.
If NTP is not being used, manual adjustment of the system clock will be required after the leap second has passed.

There should be no need caring about the leap-seconds-file as the leap second gets properly respected by the ntp-servers used except systems without correct and stable NTP service.
 
I noticed the bug. It was there back in 2022. But it was fixed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262031
Code:
Oct 27 16:50:44 none ntpd[911]: Cannot set RLIMIT_MEMLOCK: Operation not permitted
Oct 27 16:50:44 none ntpd[911]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
Oct 27 16:50:44 none ntpd[911]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2025-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
 
Back
Top