[ntp:questions] Leap second indication (Linux NTPD specifically)

unruh unruh at invalid.ca
Tue Mar 6 19:01:27 UTC 2012

On 2012-03-06, Phil Fisher <Phil.Fisher at ipaccess.com> wrote:
> Hi Dave
> 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).
> Phil
> 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.

No memory. IF the leap flag is there  and is positive, then at 23:59:59
of June 30 UTC, an extra second will be inserted, so that 23:59:60
occurs. That is it. That is the leapsecond. (if the flag is negative,
then 23:59:59 is omitted). That is it. There is nothing else to "insert"
There is nothing to remember. 

> -----Original Message-----
> 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: 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" "fudge
> 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
> system.
> 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.
> Cheers,
> Dave Hart
> 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 mailing list