[ntp:questions] Leap Second testing

Phil Fisher Phil.Fisher at ipaccess.com
Wed May 9 15:12:12 UTC 2012


Dave
Thanks for the reply.

I have now checked what has happened even more carefully and I conclude the problem originated with the installation of the adjtimex program/RPM.

It would seem I (or someone else not sure) ran adjtimex -status to set the leap indicator after it was installed (probably me but my history setting ain't that good).

Once this was done, then ntptime indicates that it has been set even if the current status shows it is not.  In my opinion this is at best fallacious if not a bug.  If the Leap indicator is cleared then I would not expect it to be remembered somewhere else why bother clearing it and providing the facilities to clear it.

Therefore my testing scenario will have to ensure that LI has not been set at any point.  I assume from your comments both in response to this post and earlier ones that LI can only be propagated by an upstream NTP server (assuming here that the client is not a stratum 1 server of course) to the downstream client on the day that a Leap Second should be implemented (and by day I understand this to be the UTC day which could be a whole can of worms in itself when people think of local time and when this can occur).

If this is correct, then using ntptime -r once can check that a LI has not already been seen (since that will show a return status of 1 (INS) while the status will show as 17 (0x0011) (PLL,INS) typically. If we try to cancel it then the results will show return status of 1 (INS) but the status as 1 (PLL).  It will be important for me to detect this (even if the consensus of NTP gurus is it would not occur and is not a problem) since I might need to take action that stops the possibility of the Linux kernel bug occurring.

I think it might well be important in real world scenarios where an incorrect deployment may have triggered an incorrect LI to downstream clients.  There should be a way to clear this (and ntptime -s clearly allows this) but not completely hence leading to an incorrect adding of a leap second and possibly in older Linux kernels a system crash when logging the leap second event.

Phil


-----Original Message-----
From: Dave Hart [mailto:hart at ntp.org] 
Sent: 09 May 2012 15:24
To: Phil Fisher
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] Leap Second testing

On Wed, May 9, 2012 at 8:44 AM, Phil Fisher <Phil.Fisher at ipaccess.com> wrote:
> I was using ntptime to set the status bits for a system running a server
> (Centos 5, ntpd 4.2.2p1).  Tis allowed me to set the LI indicator and
> apparently to clear it.  The output from ntptime is shown at the end of this
> message. When I look at the syslog (/var/log/messages) I see what
> seems to be a +1 second jump at about 0200 earlier today -- my system
> runs BST (== GMT+1/UTC+1). Even more bizarre I see that a leap
> second was inserted at about 0100!
>
> Why bizarre?  Because although I had turned on the LI bit via
> ntptime/adjtimex I had also cleared it almost immediately since I was
> testing possibilities not implementation.  Subsequent checks seemed
> to show that the LI was clear in the status.  Therefore I was not expecting
> any Leap Second activity.

It appears there are two ways a pending leap insertion is indicated by
ntp_gettime/ntp_adjtime.  You were paying attention to the status word
0x10 bit.  The other way is the return value of the function.  Notice
even your last ntptime invocation reported (INS) regarding the return
values from ntp_gettime and ntp_adjtime.

No, I don't know why the two are not in sync.  I'm not particularly
worried about it, either, unless it causes a real-world problem.

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