[opensuse] Recent leap second

older
[opensuse] /etc/permissions.d on...

Roger Oberholtzer

3 Jan 2017 3 Jan '17

10:14

At the end of 2016, my openSUSE system reported: Clock: inserting leap second 23:59:60 UTC This always worries me, as there are a number of links in the chain. And it seems any can insert a leap second. I have two configurations on openSUSE systems: Use ntpd to sync time with a time server. My local ntp can be told whether to insert leap seconds. I have to assume that the ntp protocol ensures that the time communicated between systems is properly identified as to whether it has a leap second adjustment or not. gpsd and chrony. gpsd, it seems, can have a compiled-in leap second offset. If I understand this correctly, this offset will be added to the time gpsd makes available to clients. Can the clients know this offset has been added? chrony can also add a leap second, depending on how it is configured. In all cases, I am using openSUSE-compiled binaries. Is there a coordinated discussion of how these apps are compiled and configured (e.g., ntpd via yast)? Especially as relates to leap seconds. Redhat have some info at https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-lea.... But that still does not address how the deliverables are actually configured when compiled and then configured for use. The reason I am so interested is that we have been working to use the system clock (set with gpsd/chrony) to timestamp data via gettimeofday(). That time can be used to locate things in the GPS location data. The GPS time does not have leap seconds. So we are trying to be sure we have not missed anything. The data is collected in a moving vehicle. At 90 km/h, each second of error is 25 meters. So it is a rather important thing to track... Knowing how this is dealt with through the complete openSUSE chain is important. All pointers to information are welcome. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Per Jessen

3 Jan 3 Jan

10:42

Roger Oberholtzer wrote:

...

At the end of 2016, my openSUSE system reported:

Clock: inserting leap second 23:59:60 UTC

I can't seem to find that one anywhere. In /var/log/ntp, I see this on some systems: 1 Jan 01:08:16 ntpd[1896]: kernel reports leap second has occurred

...

This always worries me, as there are a number of links in the chain. And it seems any can insert a leap second.

It was on TV only a few days ago, probably on New Year's Eve - when Earth's rotation has changed and the length of a day thereby has changed more than 0.9second, a leap second is introduced. I thought they said the decision to introduce a leap second was up to some committee under the ITU ? -- Per Jessen, Zürich (-1.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

11:02

Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
At the end of 2016, my openSUSE system reported:

Clock: inserting leap second 23:59:60 UTC

I can't seem to find that one anywhere.

Correction, found them, I was looking in the wrong place.

...

In /var/log/ntp, I see this on some systems:

1 Jan 01:08:16 ntpd[1896]: kernel reports leap second has occurred

...
This always worries me, as there are a number of links in the chain. And it seems any can insert a leap second.

Isn't that up to your time-server? -- Per Jessen, Zürich (-0.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

11:08

Per Jessen wrote:

...

It was on TV only a few days ago, probably on New Year's Eve - when Earth's rotation has changed and the length of a day thereby has changed more than 0.9second, a leap second is introduced. I thought they said the decision to introduce a leap second was up to some committee under the ITU ?

uh, I was corrected off-line - it is the IERS in Frankfurt that decide whether or not to introduce a leap second. -- Per Jessen, Zürich (-0.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

11:26

If one reads about the Windows NTP client, it says that during the day the packets from the server (NTP - so it could be a Linux server) will indicate that a leap second should be done that day. But the Windows client ignores this. So, for a bit of time the client may be off by one second. But the next time sync corrects this and all is okay. Which implies that the server initially tells that a leap second is soon to happen. Then, at some point, the leap second is incorporated into the time. If my system prints the message that it did make the one second adjustment (it sets the current time back one second), the time must still get set correctly no matter if this adjustment was done. After all, it must work if my system is turned on after the second should have been added (the next day). Is this done this way so the client can choose to deal with the real leap second in some way other than the usual jitter? GPS receivers, on the other hand, do not incorporate leap seconds into their time. But they can indicate that a leap second should be added. I wonder if the information they provide is the cumulative number of leap seconds that should be added to convert GPS time into UTC time (currently 18 seconds). So, is it the case that ntp clients (ntpd, chrony), in order to set the local clock to UTC, should add leap seconds if the time source is a GPS receiver, and not add them if it is an NTP server? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

12:34

Roger Oberholtzer wrote:

...

If one reads about the Windows NTP client, it says that during the day the packets from the server (NTP - so it could be a Linux server) will indicate that a leap second should be done that day. But the Windows client ignores this. So, for a bit of time the client may be off by one second. But the next time sync corrects this and all is okay.

I would expect a local client to be sync'ed all the time - our time server uses DFC77 as a source, and if/when reception deteriorates, it will fall back to a stratus 1 server. When that happens I see a sync event in the logs: 3 Jan 00:28:14 ntpd[21087]: synchronized to 162.23.41.10, stratum 1 3 Jan 00:36:50 ntpd[21087]: synchronized to GENERIC(0), stratum 0

...

Which implies that the server initially tells that a leap second is soon to happen. Then, at some point, the leap second is incorporated into the time.

The DFC77 signal has a leap second warning bit, afaik it is set during the hour before the leap second. Not sure what ntp does with it, presumably it's in the protocol: http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499 -- Per Jessen, Zürich (-0.5°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

13:46

On Tue, Jan 3, 2017 at 1:34 PM, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
If one reads about the Windows NTP client, it says that during the day the packets from the server (NTP - so it could be a Linux server) will indicate that a leap second should be done that day. But the Windows client ignores this. So, for a bit of time the client may be off by one second. But the next time sync corrects this and all is okay.

I would expect a local client to be sync'ed all the time - our time server uses DFC77 as a source, and if/when reception deteriorates, it will fall back to a stratus 1 server. When that happens I see a sync event in the logs:

3 Jan 00:28:14 ntpd[21087]: synchronized to 162.23.41.10, stratum 1 3 Jan 00:36:50 ntpd[21087]: synchronized to GENERIC(0), stratum 0

...
Which implies that the server initially tells that a leap second is soon to happen. Then, at some point, the leap second is incorporated into the time.

The DFC77 signal has a leap second warning bit, afaik it is set during the hour before the leap second. Not sure what ntp does with it, presumably it's in the protocol:

http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499

One of my NTP client systems (openSUSE 12.3) is rather old. I can't guess that it has information about this leap second built in. So it must have come from the NTP server. I guess it saw that this was indicated, and at midnight made the one second adjustment. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

14:32

On 2017-01-03 11:42, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
At the end of 2016, my openSUSE system reported:

Clock: inserting leap second 23:59:60 UTC

I can't seem to find that one anywhere. In /var/log/ntp, I see this on some systems:

I see it in /var/log/messages: Jan 01 00:55:01 Isengard systemd[1]: Stopped User Manager for UID 0. Jan 01 00:55:01 Isengard systemd[1]: Removed slice User Slice of root. Jan 01 00:59:59 Isengard systemd[2287]: Time has been changed Jan 01 00:59:59 Isengard kernel: Clock: inserting leap second 23:59:60 UTC <====== Jan 01 00:59:59 Isengard systemd[1]: Time has been changed Jan 01 01:00:01 Isengard cron[14493]: pam_unix(crond:session): session opened for user root by (uid=0) Jan 01 01:00:01 Isengard cron[14491]: pam_unix(crond:session): session opened for user root by (uid=0) Jan 01 01:00:01 Isengard cron[14492]: pam_unix(crond:session): session opened for user root by (uid=0) Jan 01 01:00:01 Isengard systemd[1]: Created slice User Slice of root. Jan 01 01:00:01 Isengard systemd[1]: Starting User Manager for UID 0... Jan 01 01:00:01 Isengard systemd[14494]: pam_unix(systemd-user:session): session opened for user root by (uid=0) Jan 01 01:00:01 Isengard systemd[1]: Started Session 11986 of user root. Jan 01 01:00:01 Isengard systemd[1]: Started Session 11985 of user root. Jan 01 01:00:01 Isengard systemd[1]: Started Session 11987 of user root. Jan 01 01:00:01 Isengard systemd[14494]: Reached target Timers. Jan 01 01:00:01 Isengard systemd[14494]: Reached target Sockets. Jan 01 01:00:01 Isengard systemd[14494]: Reached target Paths. Jan 01 01:00:01 Isengard systemd[14494]: Reached target Basic System. Jan 01 01:00:01 Isengard systemd[14494]: Reached target Default. Jan 01 01:00:01 Isengard systemd[14494]: Startup finished in 67ms. Jan 01 01:00:01 Isengard systemd[1]: Started User Manager for UID 0. Jan 01 01:00:01 Isengard CRON[14491]: pam_unix(crond:session): session closed for user root Jan 01 01:00:02 Isengard CRON[14493]: pam_unix(crond:session): session closed for user root Syslog clock has more precision: 3.6> 2017-01-01T00:55:01.837980+01:00 Isengard systemd 1 - - Removed slice User Slice of root. <3.6> 2017-01-01T00:59:59.007234+01:00 Isengard systemd 2287 - - Time has been changed <0.5> 2017-01-01T00:59:59.010999+01:00 Isengard kernel - - - [2151678.465702] Clock: inserting leap second 23:59:60 UTC <====== <3.6> 2017-01-01T00:59:59.014058+01:00 Isengard systemd 1 - - Time has been changed <10.6> 2017-01-01T01:00:01.763744+01:00 Isengard cron 14493 - - pam_unix(crond:session): session opened for user root by (uid=0) I understand this second propagates over nntp in some manner. Either explicitly, or as a consequence of the system clocks having adjusted for it. 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. Now, the next step is learning what happens at a stratum one server. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Wols Lists

4 Jan 4 Jan

19:25

On 03/01/17 14:32, Carlos E. R. wrote:

...

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.

Now, the next step is learning what happens at a stratum one server.

Depends on what software the server is running ... (afaik). The consensus (because the standard specifies 60 seconds per minute) is that 23:59:59 should happen twice. This relies on the server setting the warning, and the client acting on it. BUT WATCH OUT. I gather some time servers - Google in particular - accumulate a deliberate error (presumably of about .0003s/s) over the preceding day so that come midnight the clock is one second slow and the leap second puts it right. Which is fine UNTIL you need to be able to measure seconds accurately! The big problem is out current clock definition cannot cope with a 61-second minute, so all we have is ad-hoc fixes. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

5 Jan 5 Jan

09:11

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. 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". 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, -- Per Jessen, Zürich (-1.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

09:13

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

s/ntp_timeadj/ntp_adjtime/ it's a syscall. -- Per Jessen, Zürich (-0.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

14:44

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)

Roger Oberholtzer

15:14

On Thu, Jan 5, 2017 at 3:44 PM, Carlos E. R. wrote:

...

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.

I don't think the kernel needs this information or even knows about leap seconds. When using ntp, the kernel just does what it is told. ntp decides how to change the time. The info that tells that a leap second is soon to happen lets ntp update that change in a possibly different way than how it handles normal jitter. How ntp does this is configured. This is sort of what my original question was addressing: who adds the leap seconds? gpsd or ntp/chrony or the kernel? Does NTP have the leap seconds built in? Or does the ntp packet tell this? I think that is the case. The reason that the packet from the server should contain this info is that the client must get this correct if it is started after that last leap second has happened. The bigger mystery to me is strptime(3), which must be able to convert seconds to/from a date, and the date can be any one in the Unix epoch or even the future. How does it know if ntp applied the leap seconds when maintaining kernel time from which the date was derived? I think it uses a database for the timezone to decide when leap seconds have happened. But if your database is not up-to-date? And if the leap seconds were not used when the date was obtained?

...

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.

:60 cannot be represented. So what happens is that the time is changed from something like :59 to :58. Resulting in one additional second needed. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

15:33

Roger Oberholtzer wrote:

...

On Thu, Jan 5, 2017 at 3:44 PM, Carlos E. R. wrote:

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

I don't think the kernel needs this information or even knows about leap seconds.

Yep, I agree.

...

When using ntp, the kernel just does what it is told. ntp decides how to change the time. The info that tells that a leap second is soon to happen lets ntp update that change in a possibly different way than how it handles normal jitter. How ntp does this is configured.

See maybe leapsmear - README.leapsmear

...

This is sort of what my original question was addressing: who adds the leap seconds? gpsd or ntp/chrony or the kernel? Does NTP have the leap seconds built in? Or does the ntp packet tell this? I think that is the case.

That is certainly the case on my setup. The leap second is announced by DCF77, and acted upon by ntpd.

...

The bigger mystery to me is strptime(3),

It seem to me that strptime() does just what we ask of it - convert a text timestamp to a "struct tm". It doesn't need to know much about anything? -- Per Jessen, Zürich (-2.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

15:39

On 2017-01-05 16:14, Roger Oberholtzer wrote:

...

On Thu, Jan 5, 2017 at 3:44 PM, Carlos E. R. wrote:

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

I don't think the kernel needs this information or even knows about leap seconds. When using ntp, the kernel just does what it is told. ntp decides how to change the time. The info that tells that a leap second is soon to happen lets ntp update that change in a possibly different way than how it handles normal jitter. How ntp does this is configured.

But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round. The leap seconds are builtin inside the kernel. This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

...

This is sort of what my original question was addressing: who adds the leap seconds? gpsd or ntp/chrony or the kernel?

Does NTP have the leap seconds built in? Or does the ntp packet tell this? I think that is the case. The reason that the packet from the server should contain this info is that the client must get this correct if it is started after that last leap second has happened.

The bigger mystery to me is strptime(3), which must be able to convert seconds to/from a date, and the date can be any one in the Unix epoch or even the future. How does it know if ntp applied the leap seconds when maintaining kernel time from which the date was derived? I think it uses a database for the timezone to decide when leap seconds have happened. But if your database is not up-to-date? And if the leap seconds were not used when the date was obtained?

One more question: at 00:00 local or UTC?

...

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

:60 cannot be represented. So what happens is that the time is changed from something like :59 to :58. Resulting in one additional second needed.

Why do you say that :60 can not be represented? It can, in computers, if the clock is programmed in software to handle it. Wall clocks can not. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Roger Oberholtzer

15:57

On Thu, Jan 5, 2017 at 4:39 PM, Carlos E. R. wrote:

...

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

I don't think the kernel needs this information or even knows about leap seconds. When using ntp, the kernel just does what it is told. ntp decides how to change the time. The info that tells that a leap second is soon to happen lets ntp update that change in a possibly different way than how it handles normal jitter. How ntp does this is configured.

But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round.

The leap seconds are builtin inside the kernel.

Maybe there is a kernel call made by ntp that does this?

...

This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

Interesting test. I think it will not add the leap second. It may also interact with the setting that tells if the hardware clock is UTC. Things like daylight savings time changes only seem to be done when the hardware clock is set to UTC.

...

One more question: at 00:00 local or UTC?

I think 00:00 UTC time. The full message was: 2017-01-01T00:59:59.001885+01:00 acme kernel: [1438619.838798] Clock: inserting leap second 23:59:60 UTC My system changed the time at 00:59:59.001885 local time, which is 23:59:60 [sic] UTC So the second must be inserted at the same instance everywhere: 23:59:60 UTC, no matter the local time. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

16:16

Roger Oberholtzer wrote:

...

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

Interesting test. I think it will not add the leap second.

Ditto. Just grep around the kernel sources, there's nothing to suggest the kernel knows about leap seconds, except if they are indicated by call to ntp_adjtime(). Most of the logic is in kernel/time/ntp.c -- Per Jessen, Zürich (-2.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

7 Jan 7 Jan

02:17

On 2017-01-05 16:57, Roger Oberholtzer wrote:

...

On Thu, Jan 5, 2017 at 4:39 PM, Carlos E. R. <> wrote:

...

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

Interesting test. I think it will not add the leap second. It may also interact with the setting that tells if the hardware clock is UTC. Things like daylight savings time changes only seem to be done when the hardware clock is set to UTC.

Yes, the handling of the CMOS clock is different when it doesn't keep UTC, and it was changed not many releases ago. It must be mentioned on one of the release notes. I don't remember right now, I still have some flu. Not fever.

...

...
One more question: at 00:00 local or UTC?

I think 00:00 UTC time. The full message was:

2017-01-01T00:59:59.001885+01:00 acme kernel: [1438619.838798] Clock: inserting leap second 23:59:60 UTC

Ah, yes.

...

My system changed the time at 00:59:59.001885 local time, which is 23:59:60 [sic] UTC

So the second must be inserted at the same instance everywhere: 23:59:60 UTC, no matter the local time.

Right. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Per Jessen

5 Jan 5 Jan

16:06

Carlos E. R. wrote:

...

But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round.

You are misreading the log, Carlos. The log message is written by ntpd after calling ntp_adjtime(). This call returns a condition or code, and ntpd just logs it, that's all.

...

The leap seconds are builtin inside the kernel.

Common sense says that simply isn't possible. My 1[123]1.x systems could not possibly know about the most recent leap second, their kernels pre-date the IERS Bulletin C 52 from July 2016 by quite a bit - yet surprisingly, they found out about the leap second. https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.52

...

This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

I'll be happy to test that tomorrow. -- Per Jessen, Zürich (-2.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

6 Jan 6 Jan

09:44

Per Jessen wrote:

...

Carlos E. R. wrote:

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

I'll be happy to test that tomorrow.

Well, I've installed Leap421 on a desktop, I've set the time to 23:50 31/12/2016. There is no ntp running nor installed, how do I now tell if the leap second is introduced or not? -- Per Jessen, Zürich (-6.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

15:02

Per Jessen wrote:

...

Per Jessen wrote:

...
Carlos E. R. wrote:

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

I'll be happy to test that tomorrow.

Well, I've installed Leap421 on a desktop, I've set the time to 23:50 31/12/2016. There is no ntp running nor installed, how do I now tell if the leap second is introduced or not?

Well, as it is ntpd that is reporting on the leap second, I'm going to install it and see if I can prevent dhcp from dishing out a time-server to it. That should give me a stand-alone ntpd. -- Per Jessen, Zürich (-5.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

7 Jan 7 Jan

02:31

On 2017-01-06 10:44, Per Jessen wrote:

...

Per Jessen wrote:

...
Carlos E. R. wrote:

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

I'll be happy to test that tomorrow.

Well, I've installed Leap421 on a desktop, I've set the time to 23:50 31/12/2016. There is no ntp running nor installed, how do I now tell if the leap second is introduced or not?

I tried with 42.2 the same thing, and didn't see anything in the log. One way to check is write a little script that loops and print the time to a file (with milliseconds precision at least), then sleeps a second. I used that trick ages ago to test for an issue I had. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Per Jessen

09:07

Carlos E. R. wrote:

...

On 2017-01-06 10:44, Per Jessen wrote:

...
Per Jessen wrote:

...
Carlos E. R. wrote:

...
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.

I'll be happy to test that tomorrow.

Well, I've installed Leap421 on a desktop, I've set the time to 23:50 31/12/2016. There is no ntp running nor installed, how do I now tell if the leap second is introduced or not?

I tried with 42.2 the same thing, and didn't see anything in the log.

One way to check is write a little script that loops and print the time to a file (with milliseconds precision at least), then sleeps a second. I used that trick ages ago to test for an issue I had.

Well, the test worked - without someone prodding it, as I was certain it couldn't, the kernel knows nothing about any leap seconds. Just now, I set system time to 31 Dec 23:50 UTC, rebooted, let ntp sync to LOCAL: /var/log/ntp: 1 Jan 00:50:53 ntpd[1491]: 0.0.0.0 c01d 0d kern kernel time sync enabled 1 Jan 00:50:53 ntpd[1491]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 1 Jan 00:50:53 ntpd[1491]: 0.0.0.0 c016 06 restart 1 Jan 00:56:14 ntpd[1491]: 0.0.0.0 c515 05 clock_sync office31:~ # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.1.0 .LOCL. 10 l 52 64 377 0.000 0.000 0.000 No mention of any leap seconds in /var/log/messages nor /var/log/ntp. -- Per Jessen, Zürich (-7.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

13:44

On 2017-01-05 17:06, Per Jessen wrote:

...

Carlos E. R. wrote:

...
But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round.

You are misreading the log, Carlos.

The log message is written by ntpd after calling ntp_adjtime(). This call returns a condition or code, and ntpd just logs it, that's all.

...
The leap seconds are builtin inside the kernel.

Common sense says that simply isn't possible. My 1[123]1.x systems could not possibly know about the most recent leap second, their kernels pre-date the IERS Bulletin C 52 from July 2016 by quite a bit - yet surprisingly, they found out about the leap second.

That's an important point. Yet the command "date" does know about leap seconds. it mentions that in the manual. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Andrei Borzenkov

15:07

07.01.2017 16:44, Carlos E. R. пишет:

...

On 2017-01-05 17:06, Per Jessen wrote:

...
Carlos E. R. wrote:

...
But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round.

You are misreading the log, Carlos.

The log message is written by ntpd after calling ntp_adjtime(). This call returns a condition or code, and ntpd just logs it, that's all.

...
The leap seconds are builtin inside the kernel.

Common sense says that simply isn't possible. My 1[123]1.x systems could not possibly know about the most recent leap second, their kernels pre-date the IERS Bulletin C 52 from July 2016 by quite a bit - yet surprisingly, they found out about the leap second.

That's an important point.

Yet the command "date" does know about leap seconds.

No, it does not. Have you tried?

...

it mentions that in the manual.

It says "*if* system supports leap seconds".

Carlos E. R.

8 Jan 8 Jan

17:13

On 2017-01-07 16:07, Andrei Borzenkov wrote:

...

07.01.2017 16:44, Carlos E. R. пишет:

...

...
Yet the command "date" does know about leap seconds.

No, it does not. Have you tried?

I did, yes, but I failed to concoct an appropriate command line.

...

...
it mentions that in the manual.

It says "*if* system supports leap seconds".

That detail escaped my attention. Sigh :-( -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Per Jessen

5 Jan 5 Jan

15:24

Carlos E. R. wrote:

...

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

Sure, but that is after being instructed to do so by NTP.

...

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,

Uh no, that's not really it. ntp has called ntp_adjtime() and the return code indicates ("kernel reports") that a leap second is going to be inserted. ntpd just writes a log message to indicate that.

...

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.

Yes it is.

...

My read is that the kernel has the leap second (hard/soft)coded into it somewhere.

ntpd has the known leap seconds hardcoded in some test utilities, but obviously cannot have any future ditto. The kernel has nothing, to my knowledge.

...

After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.

I'm not sure it does. If you run a system without ntpd, and instead relying only on the RTC, you'll end up with a clock way out of touch with reality, that's all :-) -- Per Jessen, Zürich (-0.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

15:50

On 2017-01-05 16:24, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...
After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.

I'm not sure it does. If you run a system without ntpd, and instead relying only on the RTC, you'll end up with a clock way out of touch with reality, that's all :-)

See "info date", it mentions leap second handling. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Per Jessen

15:54

Carlos E. R. wrote:

...

On 2017-01-05 16:24, Per Jessen wrote:

...
Carlos E. R. wrote:

...
...
After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.

I'm not sure it does. If you run a system without ntpd, and instead relying only on the RTC, you'll end up with a clock way out of touch with reality, that's all :-)

See "info date", it mentions leap second handling.

How is that relevant to this debate? Perhaps you could extract the pertinent bits. -- Per Jessen, Zürich (-2.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

7 Jan 7 Jan

02:38

On 2017-01-05 16:54, Per Jessen wrote:

...

Carlos E. R. wrote:

...
On 2017-01-05 16:24, Per Jessen wrote:

...
Carlos E. R. wrote:

...
...
After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.

I'm not sure it does. If you run a system without ntpd, and instead relying only on the RTC, you'll end up with a clock way out of touch with reality, that's all :-)

See "info date", it mentions leap second handling.

How is that relevant to this debate? Perhaps you could extract the pertinent bits.

Well, I don't know where that information is coded. It could get that info from the kernel, maybe from glib, or maybe it has that information is in the user application "date" itself. My theory is that the kernel has this information available and time functions have it available for time calculations. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Andrei Borzenkov

08:05

07.01.2017 05:38, Carlos E. R. пишет:

...

On 2017-01-05 16:54, Per Jessen wrote:

...
Carlos E. R. wrote:

...
On 2017-01-05 16:24, Per Jessen wrote:

...
Carlos E. R. wrote:

...
...
After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.

I'm not sure it does. If you run a system without ntpd, and instead relying only on the RTC, you'll end up with a clock way out of touch with reality, that's all :-)

See "info date", it mentions leap second handling.

How is that relevant to this debate? Perhaps you could extract the pertinent bits.

Well, I don't know where that information is coded. It

It is coded in timezone file but as far as I can tell Linux date command does not use it.

...

could get that info from the kernel, maybe from glib, or maybe it has that information is in the user application "date" itself.

My theory is that the kernel has this information available and time functions have it available for time calculations.

2667

Age (days ago)

2672

Last active (days ago)

List overview

Download

30 comments

5 participants

participants (5)

Andrei Borzenkov
Carlos E. R.
Per Jessen
Roger Oberholtzer
Wols Lists