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:[email protected]] Sent: 09 May 2012 15:24 To: Phil Fisher Cc: [email protected] Subject: Re: [ntp:questions] Leap Second testing On Wed, May 9, 2012 at 8:44 AM, Phil Fisher <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
