Solved Leapseconds file expired

F

freejetz888

Hello all, running FreeBSD 10.3 with ntpd enabled through rc.conf with these lines
Code: 
ntpd_enable="YES"
ntpd_sync_on_start="YES"
I started receiving this message at startup
Code: 
ntpd[655]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired less than 17 days ago
I take a look at my leap-seconds.list at /var/db/ntpd.leap-seconds.list and sure enough it is expired:
Code: 
#       Updated through IERS Bulletin C 50
#       File expires on:  1 Jun 2016
I take a look at /etc/ntp.conf and it has this blurb about the leapseconds
Code: 
# See http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.
# for documentation regarding leapfile. Updates to the file can be obtained
# from ftp://time.nist.gov/pub/ or ftp://tycho.usno.navy.mil/pub/ntp/.
# Use either leapfile in /etc/ntp or weekly updated leapfile in /var/db.
#leapfile "/etc/ntp/leap-seconds"
leapfile "/var/db/ntpd.leap-seconds.list"
Both files(/etc/ntp/leap-seconds and /var/db/ntpd.leap-seconds) noted here have the same expiration date of 1 Jun 2016. I've attempted the #ntpd fetch and #service ntpd fetch commands with no luck. The files at the web locations noted have expiration in Dec 2016.

I've gone into the periodic.conf and enabled the periodic then run it with no luck.
Code: 
# 480.leapfile-ntpd
daily_ntpd_leapfile_enable="YES"                        # Fetch NTP leapfile
daily_ntpd_avoid_congestion="NO"                        # Avoid congesting
                                                        # leapfile sources
Is there anything I'm missing? Any help would be greatly appreciated.
 
Last edited by a moderator:
I believe the message is correct and just informational. On my system the leap seconds file has entries only up to the last time the leap seconds were added and it's probable that the new file won't be distributed until there's again a need to add a leap second to clocks.
 
That doesn't seem to fetch anything new. This is the output after putting ntp_leapfile_fetch_verbose="YES" in /etc/rc.conf.
Code: 
% sudo service ntpd onefetch
ntp_src_leapfile version is 3660508800
ntp_db_leapfile version is 3660508800
not replacing /var/db/ntpd.leap-seconds.list with /etc/ntp/leap-seconds
Within ntp leapfile expiry limit, initiating fetch
fetching https://www.ietf.org/timezones/data/leap-seconds.list
using existing /var/db/ntpd.leap-seconds.list
To get the new one you can (temorarily) put ntp_leapfile_sources="ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list" in /etc/rc.conf.
Code: 
% sudo service ntpd onefetch
ntp_src_leapfile version is 3660508800
ntp_db_leapfile version is 3660508800
not replacing /var/db/ntpd.leap-seconds.list with /etc/ntp/leap-seconds
Within ntp leapfile expiry limit, initiating fetch
fetching ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list
using ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list as /var/db/ntpd.leap-seconds.list
 
Thanks all for the help on this issue.

I ended up going in and adding the line the the rc.conf file as jrm suggested and ran service ntpd onefetch. After a reboot the file expired message is gone and the new file has an expiry of 1 Dec 2016.
 
Bearing in mind that this file should be updated on a regular basis - it is better to place it on the FreeBSD infrastructure and updated regularly, rather than on servers with poor connectedness.
 
Leap seconds do not occur very often (every 3 to 4 years with the Earth's current rotational characteristics), and the file is normally only updated twice per year. Between the copies at IETF, NIST, USNO, and IERS @ OBSPM, it's widely available. All of those sites normally have reasonable connectivity.

This has only come to light because of what I see as a design flaw in the file format/spec, where the "last updated" time is the time that a new leap second was added, and not the actual true last updated time for the file itself. The USNO version of the file works around this by violating the specification and matching the update time to the file as a whole, where the IETF version (the one used by FreeBSD by default) does not.

FreeBSD has already fixed the issue by changing /etc/rc.d/ntpd to use the expiry time, in revision 300638. Hopefully that fix will get issued as an errata sometime soon, but it is also a very trivial change which you could easily add to your local system with very low risk. In the meantime, there is no pending leap second (unless something exceptional happens, IERS have confirmed that there will be no leap second in 2016, and we are not really expecting the next leap second before 2018 or 2019).

It is not an officially supported way of doing things (i.e. caveat emptor), but you can grab the fixed /etc/rc.d/ntpd direct from SVN:
 
cvb said:
Then why this new file contains this string?
# File expires on: 1 Dec 2016
Click to expand...
That's perfectly normal. The IERS issues a new bulletin every 6 months (unless exceptional circumstances dictate otherwise, such as an unexpected change to the Earth's rotation). The next bulletin is expected in July 2016, then the various editions of the leap seconds files will be updated between July and December. The expiration date of the file is just that — the maximum validity of the data in it at the time the file was last updated. It gives no indication of when the data will next actually change. The July 2016 edition of the data should be unchanged (just with an expiry date of June 2017). The data in the leap seconds file has not changed since 2014/2015.

Based on what the IERS have said about the Earth's rotation, we are not expecting a leap second before 2018, but they don't guarantee things quite so far into the future. They issue regular bulletins regardless of when the next leap second is expected, so that they only commit to it around 6 to 12 months prior to it being inserted into UTC.
 
cvb said:
Then why this new file contains this string?
# File expires on: 1 Dec 2016
Click to expand...

I would guess that the intention is to make a new file available before the expiry time has been reached so that the ntp services will make a check for a potential new leap second should one happen.
 
This is interesting. I've followed these instructions for automating (to some degree) the fetch process, now here's the system's message:
Code: 
ntp_src_leapfile version is 3676752000
ntp_db_leapfile version is 3676924800
not replacing /var/db/ntpd.leap-seconds.list with /etc/ntp/leap-seconds
Just wonder how come the ntp_src_leapfile from that USNO server is older than my system one. BTW, the existing one I manually downloaded from one of the other servers, don't remember which.
 
free-and-bsd said:
This is interesting. I've followed these instructions for automating (to some degree) the fetch process, now here's the system's message:
Code: 
ntp_src_leapfile version is 3676752000
ntp_db_leapfile version is 3676924800
not replacing /var/db/ntpd.leap-seconds.list with /etc/ntp/leap-seconds
Just wonder how come the ntp_src_leapfile from that USNO server is older than my system one. BTW, the existing one I manually downloaded from one of the other servers, don't remember which.
Click to expand...

Following the instructions provided by dvl@ should fix your current problem

https://dan.langille.org/2016/08/03...ap-seconds-list-expired-less-than-n-days-ago/
 
cpm@ said:
Following the instructions provided by dvl@ should fix your current problem

https://dan.langille.org/2016/08/03...ap-seconds-list-expired-less-than-n-days-ago/
Click to expand...
You know the funny thing? I got this link in your post even before you posted it :). There are not very many posts on this, it seems...

However, I'm running 11 and the article recommends a patch from STABLE (10). As expected, then, my /etc/rc.d/ntpd seems to already have the changes from that patch.
Besides, my ntpd doesn't complain (any more) about the file having expired. I just don't get it how it is that
Code: 
ntp_src_leapfile version is 3676752000
while
Code: 
ntp_db_leapfile version is 3676924800
. Are they not supposed to be at least the same version, rather than my local one being the most recent of the two?
 
free-and-bsd said:
Besides, my ntpd doesn't complain (any more) about the file having expired. I just don't get it how it is that
Code: 
ntp_src_leapfile version is 3676752000
while
Code: 
ntp_db_leapfile version is 3676924800
. Are they not supposed to be at least the same version, rather than my local one being the most recent of the two?
Click to expand...

You can find a good explanation in the following PR 209577.

In addition, you have a chance to know how the daily periodic 480.leapfile-ntpd script works for further details.

https://lists.freebsd.org/pipermail/freebsd-questions/2016-October/274183.html
 
This may or may not be off-topic, but since there's a current thread about it...

I was reading through this, and since I have a fresh install of FreeBSD 11.0-REL-p11, I decided to update my leap seconds file manually (I configured ntp.conf yesterday night), and I get the following out:

Code: 
root@00:/home/poorandunlucky # service ntpd onefetch
Certificate verification failed for /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
34374329736:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1264:
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Authentication error
root@00:/home/poorandunlucky #

what's up? anyone knows off the bat?
 
Good, Thanks to "Mugz". I solve this issue on FreeBSD 11.2
I have
Code: 
ntpd_enable="YES"
into /etc/rc.conf
Code: 
cd /usr/ports/security/ca_root_nss/
make config
make install clean
===>  Cleaning for perl5-5.26.2
===>  Cleaning for ca_root_nss-3.38
service ntpd fetch
 
While the fix from "Mugz" helped me out last time, I'm seeing the error again and I already have ca_root_nss-3.40.1 installed. From my daily periodic report
Code: 
Certificate verification failed for /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
34374371912:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Authentication error
thanks
andrew
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top