[ntp:questions] Re: HOWTO prepare ntpd to the leap of a second
David L. Mills
mills at udel.edu
Fri Dec 23 02:08:02 UTC 2005
I can't speak for previos ntpd versions since the last leap event at the
end of 1998, but I can say the current version here does correctly
insert the leap.
Be advised, as in many previous posts, the kernel must include
provisions to implement the leap. The ntpd does not actually do the
leap, just tell the kernel to do it. So far as I know, FreeBSD, Linux,
Solaris and Tru64 (ALpha) have the code from me. While FreeBSD and
Solaris have it in the released code, others may have to patch or
recompile the kerel. I know HP-UX does not have those functions,
although I implemented them for that system many years ago.
Plan A: Fetch the leapseconds file from time.nist.gov and install in the
same place the Autokey files are stored. Autokey must be running in
order to load that file so the leap bits can be correctly set.
Plan B: Rely on upstream servers to set the leap bits. If any of them
set the bits, your machine will set the bits. Be advised, the NIST and
USNO servers I poked just now do not at this time set the bits. The Udel
servers pogo, rackety and louie shine the bits properly now.
Plan C: If running Autokey with one or more upstream servers with the
leapseconds file, the file will be automatically loaded in your machine.
This is so your applications can see the bits and TAI offset in the
The Autokey protocol is restarted automaticall once each day and
refreshes the leapseconds file, but only from the direct upstream
server, which may or may not have the file. Currently, neither NIST nor
USNO run Autokey. A script can easily hijack the file by ftp from NIST,
but this is not a matter for NTP.
Serge Bets wrote:
> I would like a review of this nano-HOWTO prepare ntpd to the leap of a
> second. Any comments and enhancements are welcome. Especially reports on
> different ntpd versions. And any ideas about automated refreshing of the
> NIST file twice a year in a way that must be network friendly, NIST
> servers friendly, and secure. Is there some https://URL to get only
> HOWTO prepare ntpd to the leap of a second
> This procedure uses the NIST leap-seconds file to inform the NTP daemon
> about the absence or existence of an upcoming leap second event. It
> cooperates well with any sync source(s) you may use, even if they convey
> good, wrong, late, or no leap bits at all. The NTP daemon will always
> serve clean leap bits to its downstream clients, around 1 month before
> the event.
> Step-by-step procedure: On your master NTP server(s), do as root:
> 0) If you use autokey authentication, cd to the keysdir directory, and
> goto step (3).
> 1) Create an /etc/ntp directory, cd there, and create host parameters
> (as if you were using autokey feature):
> | # mkdir /etc/ntp
> | # cd /etc/ntp
> | # ntp-keygen -H -p password
> 2) Add to ntp.conf those two lines:
> | keysdir /etc/ntp
> | crypto pw password
> 3) Download the NIST leapseconds file leap-seconds.3331497600 (or
> latest) from ftp://time.nist.gov/pub/ by passive ftp.
> 4) Make a symlink from the generic name ntpkey_leap to the file:
> | # ln -s leap-seconds.3331497600 ntpkey_leap
> 5) Restart the NTP daemon. After it is synced, you can verify all worked
> well using the ntpq readvar command, by looking at the date of last
> modification of the data, and checking the current TAI offset:
> | $ ntpq -c "rv 0 leapsec,tai"
> | assID=0 status=4234 leap_add_sec, sync_lf_clock, 3 events, event_peer/strat_chg,
> | leapsec=200507280000, tai=32
> - Some older ntpd used "leapseconds" variable giving the NTP timestamp,
> instead of "leapsec" printing a human readable date.
> - Before the NTP daemon is synced for the first time, it is normal to
> see tai=0, because the current date is not yet known for sure.
> - You can apply this procedure on all hosts running ntpd, only on
> servers, or even only on your clique of lowest stratum master servers.
> In any case the leap bits will flow down on clients. And additionally,
> if you use autokey, the data in the file (not the file itself) will be
> sent to the authenticating clients, with the implied TAI offset.
> - NIST leap-seconds file has an expiration date, currently 28 June 2006
> which is 2 days before the following possibility of a leap second event.
> Make sure to refresh the file before this date, at anytime between
> February and May 2006.
> - Orphan mode in some conditions breaks leap bits.
> - This procedure is tested with ntp-dev-4.2.0b-20051208.tar.gz version
> on Linux, and ntp-dev-4.2.0b-20051105-nt.zip on Windows.
> Thankfully, Serge.
More information about the questions