[ntp:questions] Leap second indication (Linux NTPD specifically)
Phil.Fisher at ipaccess.com
Tue Mar 6 16:28:45 UTC 2012
Thanks for the input that is the sort of information I was looking (but regretfully failed to find -- not sure why since your message certainly implies it should be in ntp.conf documentation).
For sure we will be (in fact are) undertaking testing -- but without knowing the parameters it would seem silly to test especially as I prefer testing when I know what are the expected outcomes.
Your message also seems to suggest there is a bug inserting the leap second in the kernel; AFAIK the bug is in the printk() routine not the actual kernel time code (kernel/timer.c on Linux). Or is this another NTP leap second bug that I have not known about or noticed? (I apologise for any foolishness here -- I have not used this forum before and may searches may have been too restrictive to pick up other pertinent bugs/information).
P.S. The reasons for NTPD shutdown for days prior to Leap Second event are because no-one has yet been able to tell me whether the Linux 2.6.9 kernel has "memory" of a LI event such that it _will_ try to deal with it independent of any further NTPd/NTP interaction. And if such "memory" does exist then the suggestion I have will of course fail miserably.
From: Dave Hart [mailto:hart at ntp.org]
Sent: 06 March 2012 15:23
To: Phil Fisher
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] Leap second indication (Linux NTPD specifically)
To answer your questions you need two test systems (which could be
VMs). On one, load a recent-enough ntpd that you can load a
"leapfile" using ntp.conf that schedules the insertion for the end of
June 2012. If that system's OS also happens to have the bug inserting
leap seconds in the kernel NTP loop discipline, disable its use with
"disable kernel" in ntp.conf. Set up its ntpd with no sources except
a single undisciplined local clock driver "server 127.127.1.0" "fudge
127.127.1.0 stratum 10". On the second system, use the
commercially-mandated kernel and ntpd versions, and configure a single
"server" line referring to the IP address or hostname of the first
Now shut down ntpd on both systems. Set the clock on the first system
to 5 minutes before the end of the June 2012. Restart ntpd on both
systems. Verify the second system tickles the kernel bug while the
first doesn't. Add "disable kernel" to ntp.conf on the second system.
Repeat the experiment. Now both should handle the leapsecond
insertion relatively smoothly.
Note that with "disable kernel" ntpd will step the system clock back
1s sometime during the leap second, and any applications depending on
the clock to increase monotonically during that period may be unhappy.
In short: disable kernel should avoid tickling the bug without
necessarily shutting down ntpd, but if you need a monotonically
increasing clock, you may still be better off to shut down the entire
system for a minute or so at the end of June. Shutting down ntpd or
the system for days would be gross overkill. Relying on expectations
without testing invites surprise.
This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately.
ip.access Ltd, registration number 3400157, Building 2020,
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
More information about the questions