On Fri, Mar 6, 2015 at 3:15 PM, Chris Adams <linux at cmadams.net> wrote:> > Short answer: last time it was threaded stuff like Java, the time before > it was systems under heavy kernel loads. Who knows, this time Postfix > could hang, or MySQL could corrupt databases, or something else. > Probably nothing will happen, but if you want a "cover your ass" report, > I don't think anybody has done that.I'm not looking for a research project on how to prove that the last bug has been found or not. And I'm not particularly concerned about application-level bugs. Every time a second rolls over we take a chance of hitting a new previously unknown bug. We're all taking that chance. I just want the package revisions for at least the kernel and tzdata* files and anything else where previously-found bugs related to the leap second have been fixed. What I want to know (and be able to describe concisely to a non-geek person) is that on a particular machine either that the known/expected bugs have been fixed, or that they haven't and we need to schedule a reboot. And it seems like something everyone else using a distribution would want to know as well, at least for machines where scheduling a reboot is no-trivial. -- Les Mikesell lesmikesell at gmail.com
On 03/06/2015 01:41 PM, Les Mikesell wrote:> I just want the package revisions for at least the kernel and tzdata* > files and anything else where previously-found bugs related to the > leap second have been fixed.https://access.redhat.com/articles/15145 https://rhn.redhat.com/errata/RHSA-2013-0496.html Contrary to your previous assertion, in 2012, it was not the kernel that consumed CPU cycles. That problem was seen in user space. The problem was fixed by changing the kernel's implementation of leap second handling, but the reason that you are being told that testing your applications is the only way to verify that there is not a problem is that these problems aren't confined to the kernel and tzdata packages.
On Fri, Mar 6, 2015 at 4:04 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> On 03/06/2015 01:41 PM, Les Mikesell wrote: >> >> I just want the package revisions for at least the kernel and tzdata* >> files and anything else where previously-found bugs related to the >> leap second have been fixed. > > > https://access.redhat.com/articles/15145 > https://rhn.redhat.com/errata/RHSA-2013-0496.htmlHelpful, but not exactly concise... And I don't understand the concept of /usr/share/zoneinfo/right/*. Are those supposed to print the right time if your clock is left wrong?> Contrary to your previous assertion, in 2012, it was not the kernel that > consumed CPU cycles. That problem was seen in user space.But it is just as much the kernel's fault if it returns from nanosleep()/usleep() instantly without counting any time down so you spin in user space as if stayed in the kernel. Nothing in user space could have fixed it.> The problem was > fixed by changing the kernel's implementation of leap second handling, but > the reason that you are being told that testing your applications is the > only way to verify that there is not a problem is that these problems aren't > confined to the kernel and tzdata packages.Unknown problems can happen anywhere/any time. -- Les Mikesell lesmikesell at gmail.com
On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> On 03/06/2015 01:41 PM, Les Mikesell wrote: >> >> I just want the package revisions for at least the kernel and tzdata* >> files and anything else where previously-found bugs related to the >> leap second have been fixed. > > > https://access.redhat.com/articles/15145In addition to that article, the following one was updated recently: https://access.redhat.com/articles/199563 ("Are we susceptible to a leap second event?") Akemi