On Sat, Jun 30, 2012 at 21:43 UTC, Dave Hart wrote:
> Linux kernels 2.6.26 and later are reported at risk of livelock the
> day preceding the leap insertion. I haven't found the first version
> number with the fix.
http://news.ycombinator.com/item?id=4183122 indicates 3.4 is the first
corrected
It appears that my system did not respond well to the leap second.
The GPS has not yet received the leap second notification via the
satellites (it is currently still reporting an offset of 15 seconds).
The leap second was inserted by ntpd according to the leap file and then:
Jun 30 23:59:58
Linux kernels 2.6.26 and later are reported at risk of livelock the
day preceding the leap insertion. I haven't found the first version
number with the fix. This is distinct from the earlier bug logging
the actual insertion event.
http://serverfault.com/questions/403732/anyone-else-experiencing-
If your ntpd is relying upon other NTP servers (that is, is stratum 2
or higher), it will not announce the pending leap second starting
exactly at midnight UTC in a few minutes, but should within a few
polling intervals. With the default maximum interval of 1024 seconds
being about 17 minutes, by
On 6/29/2012 16:57, Dave Hart wrote:
I know, leap second preparedness is like sneeze preparedness to people
who have a life. But if you care about the pending hole in computers'
timeline, in about 2 minutes ntpd systems around the world will begin
announcing leap=01 instead of leap=00. If you a
