similar to: leap second and Centos

> -----Original Message----- > From: Akemi Yagi > Sent: Thursday, January 15, 2015 12:05 > > On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote: > > > > Hi. > > > > We have another leap second coming. Have past bugs with > Centos and leap > > seconds (specifically high CPU spikes) been resolved? > Should we be worried?

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:

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

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/15145 In

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,

On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote: > > Hi. > > 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

Hello. We have a number of Xen 3.4.2. boxes which have constant iowaits at around 10% with spikes up to 100% when accessing data over NFS. We have been unable to nail down the issue. Any advice? System info: release : 2.6.18-194.3.1.el5xen version : #1 SMP Thu May 13 13:49:53 EDT 2010 machine : x86_64 nr_cpus : 16 nr_nodes

On Tue, Jan 20, 2015 at 3:27 PM, Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote: > Unix and ntp handle leap seconds a bit differently. > Unix time increases during the leap second and drops back a second after. > Ntp freezes time during the leap second. > OS kernels may do either or neither. Does anyone have a succinct summary of how to prove to management-types that

On Thu, Jan 15, 2015 at 11:23 AM, Jason Pyeron <jpyeron at pdinc.us> wrote: > > 6 different ways of saying "Will my system work?" . > [...lots of stuff...] > [*:side bar: see http://rhn.redhat.com/errata/RHBA-2012-1199.html for the patch or do something like "date $(date +someformatthatworks)"] > Can you consolidate this to: 'if you have updated your

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

I glanced at the .leap.seconds object and noticed that it has not been updated for the most recent leap second that occurred 2005 December 31, 23h 59m 60s. See the IERS bulletin here: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Moreover, after a more careful glance at the .leap.seconds object, I noticed that there are two incorrect entries. First, there was not a leap second on 1986 June

At 2012-06-30, leap second will be introduced. ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Does Samba affect leap second? -- --- Oota Toshiya --- t-oota at dh.jp.nec.com NEC Systems Software Operations Unit Shiba,Minato,Tokyo IT Platform Solutions Division Japan,Earth,Solar system (samba-jp/ldap-jp Staff,mutt-j/samba-jp postmaster)

hi, Index: leap_second/src/library/base/R/zdatetime.R =================================================================== --- leap_second/src/library/base/R/zdatetime.R (revision 68608) +++ leap_second/src/library/base/R/zdatetime.R (working copy) @@ -24,7 +24,8 @@ "1979-12-31", "1981-6-30", "1982-6-30", "1983-6-30",

openSUSE Leap 15 has "opensuse-leap" as ID in os-release, so add it both in the detection code of the RPM handler, and in test-harder.sh. --- src/ph_rpm.ml | 2 +- tests/test-harder.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ph_rpm.ml b/src/ph_rpm.ml index b0a5eb2..3caa38e 100644 --- a/src/ph_rpm.ml +++ b/src/ph_rpm.ml @@ -40,7 +40,7 @@ let

--------------------- Kernel Begin ------------------------ 1 Time(s): Clock: inserting leap second 23:59:60 UTC ---------------------- Kernel End ------------------------- hee hee. gotta love it....

As R is sophisticated enough to track leap seconds, ?.leap.seconds we'd need to update our codes real soon now again: https://en.wikipedia.org/wiki/Leap_second (and those of you who want second precision in R in 2017 need to start working with 'R patched' or 'R devel' ...)

Hi R community! I'd like to create a temporal series with ts command for the interval 1st January 2002 - 31 December 2008. I have daily values, so this is a 2557 days temporal series. I'm using this command : ts(observations, start=2002, end=2009, freq=365) However, I don't get the correct temporal series since both frequency (365 OR 366 for leap years) and deltat (1/365 OR

Given a Date object or simply a year is there an R function to tell me if the it is a leap year or not? I was hoping for something like 'is.leapyear'. I probably can build my own function (year divisible by 4 etc.) but I would rather use an existing function if it is available. Thank you. Kevin

On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams <linux at cmadams.net> wrote: > Once upon a time, Les Mikesell <lesmikesell at gmail.com> said: >> Does anyone have a succinct summary of how to prove to >> management-types that a given linux box won't have a problem with the >> leap second? Like kernel > some_version, tzdata > some_version, >>

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