On Thu, Jan 15, 2015 at 9:04 AM, Akemi Yagi <amyagi at gmail.com> wrote:> On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote:>> We have another leap second coming. Have past bugs with Centos and leap >> seconds (specifically high CPU spikes) been resolved? Should we be worried? > > Apparently Red Hat is well aware of the upcoming leap second: > > https://access.redhat.com/solutions/1317263 > > Unfortunately all the related bugzilla reports are private so we > cannot see the status.The bugzilla reports are no longer private (thanks to whoever made them public). https://bugzilla.redhat.com/show_bug.cgi?id=1181933 (EL5) https://bugzilla.redhat.com/show_bug.cgi?id=1180536 (EL6) https://bugzilla.redhat.com/show_bug.cgi?id=1181970 (EL7) Akemi
On 01/16/2015 07:05 AM, Akemi Yagi wrote:> On Thu, Jan 15, 2015 at 9:04 AM, Akemi Yagi <amyagi at gmail.com> wrote: >> On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote: >>> We have another leap second coming. Have past bugs with Centos and leap >>> seconds (specifically high CPU spikes) been resolved? Should we be worried? >> Apparently Red Hat is well aware of the upcoming leap second: >> >> https://access.redhat.com/solutions/1317263 >> >> Unfortunately all the related bugzilla reports are private so we >> cannot see the status. > The bugzilla reports are no longer private (thanks to whoever made them public). > > https://bugzilla.redhat.com/show_bug.cgi?id=1181933 (EL5) > https://bugzilla.redhat.com/show_bug.cgi?id=1180536 (EL6) > https://bugzilla.redhat.com/show_bug.cgi?id=1181970 (EL7)Fascinating - describes what's happening but no mention of how we can rest assured that all will be well.... As I ponder it, I recognise that most of our systems are constantly calculating date/time values based upon the epoch - the number of seconds since a particular date/time, all these calculations need to be cognisant of these leap seconds, so its not just the ntp daemon, although that will be most immediately impacted, the effects of this need to be enshrined in code algorithms forever (well a very long time).> Akemi > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos
On Thu, Jan 15, 2015 at 3:00 PM, Rob Kampen <rkampen at reaching-clients.com> wrote:> > Fascinating - describes what's happening but no mention of how we can rest > assured that all will be well.... > As I ponder it, I recognise that most of our systems are constantly > calculating date/time values based upon the epoch - the number of seconds > since a particular date/time, all these calculations need to be cognisant of > these leap seconds, so its not just the ntp daemon, although that will be > most immediately impacted, the effects of this need to be enshrined in code > algorithms forever (well a very long time).The overall time calculations weren't really the issue last time around. The problem was with sub-second sleeps and the thread scheduler being confused and spinning when ntp inserted an extra second in the clock. Any other way of resetting the clock fixed it. (e.g. date -s "`date`"). It was a kernel bug and is theoretically fixed now. But I agree that those open bugs on the tzdata package aren't all that helpful except to show that someone is thinking about it. -- Les Mikesell lesmikesell at gmail.com