Sowmya Manapragada schrieb: > > Thank you Martin for all the details. These helped a lot and i could get > the leap file accepted by the server, but always leap bit leap=11 in the > rv output of server even when ,leap file is accepted by server ( i could > see in server ntpq rv 0 op as .leapsec=201507010000,expire=201612280000 > ,but leap=11) > > Please see details below: > Server Machine> Windows 7 > 1:> server ntp.conf:> > server 127.127.1.0 #sync to local clock > fudge stratum 10 > leapfile "c:\\xxxx\xxxx\xxxx\leap-seconds.3629404800" #path to > leap sec file
As Charles Elliot has pointed out in his reply, this doesn't seem to be a current leap second file. There has been an older file with this name available from NIST, but that file had an expiration date in *June* 2016. However, above you said when you run "ntpq -p" you see "expire=201612280000", which indicates that ntpd is indeed using a *current* leap second file which expires only in December 2016. So either you have saved a current leap second file under an older name, or your ntpd is using a different ntp.conf file which specifies the correct leap second file. The leap status can be "11", which means "unsynchronized", "00" which mean "synchronized", or "01" or "10" indicating a positve or negative leap second. > Am i missing something , kindly suggest. how do i know if leap sec is > added when leap=11 always, even when leap file is accepted by server. > Also any way to identify in a client taking this server time that a leap > sec is added. Your instance of ntpd is simply unsynchronized since it has no time source to synchronize to. If it used indeed the local clock it would synchronize to the local clock and only then the leap status would be "01" instead of "11". You should also see the "local clock" be listed in the output of the command "ntpq -p". So my conclusion is that the running instance of ntpd uses a different ntp.conf file than you think, which specifies the correct, current leap second file, but does not contain an entry for the local clock. Thus ntpd is unable to synchronize to some source, so there's no leap second warning to be passed to the clients, but clients wouldn't accept the server anyway since it it not synchronized. If you run ntpd as a service under Windows then the startup messages of the service in the Windows application event log include an entry "Command line:" which also contains the path the ntp.conf file specified for the service. Maybe you should check if this matches what you expect. Martin _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
