On 2017-01-05 10:11, Per Jessen wrote:
Carlos E. R. wrote:
ntp log has this:
31 Dec 02:38:57 ntpd[1749]: kernel reports leap second insertion scheduled 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred
So ntpd is told by the kernel what is going to happen, 22 hours before.
That does not make much sense - unless the kernel had been told in advance. The messages above are reports on ntp_timeadj() return codes when ntpd attempts to adjust time.
In my server, it is obvious that is what happened: Jan 01 00:59:59 Isengard kernel: Clock: inserting leap second 23:59:60 UTC (the kernel reports that it inserts...) And the ntp log confirms: 31 Dec 02:38:57 ntpd[1749]: kernel reports leap second insertion scheduled 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred About 22 hours before, the kernel tells the ntpd daemon that it is going to insert a leap second, and later it says that the kernel did in fact insert it, but at 01:03:31 - it could be that ntp log is using GPT time, not local time. My read is that the kernel has the leap second (hard/soft)coded into it somewhere. After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock. The pity is that this is not done differently: that minute should have 61 seconds. It is now impossible when seeing a timestamp 00:59:59 to know if it is the first time or the second time.
On 17 December, our time server was informed that a leap second is scheduled:
from /var/log/ntp: 17 Dec 01:40:00 ntpd[21087]: PARSE receiver #0: STATE CHANGE: LEAP ADD WARNING; TIME CODE; (LEAP INDICATION; ANTENNA) -> TIME CODE; (LEAP INDICATION; ANTENNA)
"LEAP ADD WARNING".
I don't have entries for that day: 7 Dec 03:25:22 ntpd[1749]: Listen normally on 3 eth0 192.168.1.16:123 7 Dec 03:25:22 ntpd[1749]: Listen normally on 4 lo [::1]:123 7 Dec 03:25:22 ntpd[1749]: Listen normally on 5 eth0 [fe80::4ecc:6aff:fe61:50a1%2]:123 7 Dec 03:25:22 ntpd[1749]: Listening on routing socket on fd #22 for interface updates 7 Dec 03:25:25 ntpd[1749]: receive: Unexpected origin timestamp 0xdbf1f193.cbe4e423 does not match aorg 0000000000.00000000 from server@195.186.4.100 xmt 0xdbf1f195.9584f715 7 Dec 03:25:25 ntpd[1749]: receive: Unexpected origin timestamp 0xdbf1f193.cbe6842a does not match aorg 0000000000.00000000 from server@81.19.96.148 xmt 0xdbf1f195.999f76e8 7 Dec 03:25:25 ntpd[1749]: receive: Unexpected origin timestamp 0xdbf1f193.cbdde4ad does not match aorg 0000000000.00000000 from server@212.85.158.10 xmt 0xdbf1f195.95c94011 7 Dec 03:25:25 ntpd[1749]: receive: Unexpected origin timestamp 0xdbf1f193.cbe32de5 does not match aorg 0000000000.00000000 from server@217.114.59.66 xmt 0xdbf1f195.972ec3ed 31 Dec 02:38:57 ntpd[1749]: kernel reports leap second insertion scheduled 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 3 Jan 05:12:13 ntpd[1749]: Deleting interface #3 eth0, 192.168.1.16#123, interface stats: received=23942, sent=28896, dropped=0, active_time=2339210 secs You can see that the daemon was started on the 7th, and the next entry in on the 31th Dec. It is silent for weeks. The daemon is still running, so if there are commands to interrogate and dump more info :-?
Newer clients reported "second insertion scheduled" between 10 and 20 hours earlier. Most clients said nothing. The leap second itself was announced one hour before it was due. This is with DCF77.
Now, the next step is learning what happens at a stratum one server.
Roughly the same thing. The above is a stratum 1 server,
Well, that is an important difference, mine is not. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)