Solved Leapseconds file expired

freejetz888

New Member

Reaction score: 3
Messages: 7

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:

kpa

Beastie's Twin

Reaction score: 1,801
Messages: 6,318

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.
 

ljboiler

Well-Known Member

Reaction score: 98
Messages: 331

Now that you have enabled it in periodic, it should pull the new file (the one that expires Dec 2016) with the next daily periodic run.

Manually, it's # service ntpd onefetch to get it now.
 

jrm@

Daemon
Developer

Reaction score: 473
Messages: 1,205

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
 
OP
OP
F

freejetz888

New Member

Reaction score: 3
Messages: 7

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.
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

Please, put the file leap-seconds.list to the FreeBSD project server. FTP-server tycho.usno.navy.mil is not public and don't answer to requests:

Code:
fetch ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list
fetch: transfer timed out
Tycho is a public server and is working fine right now. You must have just hit a temporary connectivity glitch.
 

cvb

New Member

Reaction score: 4
Messages: 4

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.
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

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

New Member

Reaction score: 4
Messages: 4

Then why this new file contains this string?
# File expires on: 1 Dec 2016
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

Then why this new file contains this string?
# File expires on: 1 Dec 2016
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.
 

kpa

Beastie's Twin

Reaction score: 1,801
Messages: 6,318

Then why this new file contains this string?
# File expires on: 1 Dec 2016
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.
 

free-and-bsd

Aspiring Daemon

Reaction score: 73
Messages: 665

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.
 

cpm@

Moderator
Staff member
Moderator
Developer

Reaction score: 933
Messages: 2,131

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.
Following the instructions provided by dvl@ should fix your current problem

https://dan.langille.org/2016/08/03/leapsecond-file-vardbntpd-leap-seconds-list-expired-less-than-n-days-ago/
 

free-and-bsd

Aspiring Daemon

Reaction score: 73
Messages: 665

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?
 

cpm@

Moderator
Staff member
Moderator
Developer

Reaction score: 933
Messages: 2,131

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?
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
 

poorandunlucky

Well-Known Member

Reaction score: 26
Messages: 355

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?
 

wmoreno3

Member

Reaction score: 6
Messages: 81

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
 

pez

Member

Reaction score: 7
Messages: 45

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:
Top