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

Phil Fisher Phil.Fisher at ipaccess.com
Wed Mar 7 09:13:22 UTC 2012

Hi Dave

Your comments on my semantics appreciated -- clearly I should put in the kernel version :-)
Certainly looking on the various Net sources suggests that it is printk of the Leap Second indication that causes the fault ... but good news that there is not another NTP related bug I had missed.

Your ideas in your final paragraphs are interesting so I/we shall look further.  One thing we have considered that may be helpful even if more of a hack than anything else is to use adjtimex() as suggested by a previous responder.  If my supposition that there is "memory" of LI then we can try to clear this via a call to adjtimex() -- I.e. the LI bits in status structure member.  That way we can ensure (once NTP is off) that no LI is set.

I shall certainly try to keep people updated if it is of benefit to the gurus on this list (which I doubt).

Thanks (and for the anti-groveler earlier poster, I am now upright)

-----Original Message-----
From: Dave Hart [mailto:hart at ntp.org] 
Sent: 06 March 2012 23:13
To: Phil Fisher
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] Leap second indication (Linux NTPD specifically)

On Tue, Mar 6, 2012 at 16:28, Phil Fisher <Phil.Fisher at ipaccess.com> wrote:
> 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).

Referring to the Linux kernel as "the" kernel is something I'd never
do.  I'd also never bother to distinguish that a bug exhibited by one
code path in the Linux kernel is in fact caused by a different Linux
kernel bug.  A kernel bug is a kernel bug to me.  I've heard of the
bug resulting in Linux systems crashing on leap second insertion, and
printk() rings a bell.  That is the only bug I've heard of regarding
leap seconds crashing systems.

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

This is a good point.  Using the antique kernel and ancient ntpd
you're locked into, it's quite possible the kernel will remember the
pending leap second insertion if ntpd has been run without "disable
kernel" since the OS started.  That also reminds me that prior to ntpd
4.2.7p214, anytime you switch between the kernel loop discipline and
ntpd's (with "disable kernel") you should reset the kernel loop
frequency to zero using "ntptime -f 0" to avoid ugliness due to both
ntpd and the kernel loop discipline applying similar frequency
corrections.  Restarting the OS also resets the kernel frequency
compensation to zero.

So long as ntpd has not engaged the kernel NTP code since the system
has started, the kernel code should not have any idea there is a leap
second pending to remember once ntpd stops or is restarted but
switched to the daemon (ntpd) loop discipline.

Please share the results of your testing with the group.

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