On 24/03/2015 18:54, Les Mikesell wrote:
On Tue, Mar 24, 2015 at 1:26 PM, Frank Cox thea...@melvilletheatre.com wrote:
On Tue, 24 Mar 2015 12:56:27 -0500
Les Mikesell wrote:
Doesn't anyone have a list of the oldest
kernel version for each Centos version you could be running and still
avoid
On Wed, Mar 25, 2015 at 7:41 AM, Tris Hoar trish...@bgfl.org wrote:
On 24/03/2015 18:54, Les Mikesell wrote:
On Tue, Mar 24, 2015 at 1:26 PM, Frank Cox thea...@melvilletheatre.com
wrote:
On Tue, 24 Mar 2015 12:56:27 -0500
Les Mikesell wrote:
Doesn't anyone have a list of the oldest
On Tue, 24 Mar 2015 12:56:27 -0500
Les Mikesell wrote:
Doesn't anyone have a list of the oldest
kernel version for each Centos version you could be running and still
avoid known problems?
The best answer to your question is the latest version, since previous
versions all have known issues
On Tue, Mar 24, 2015 at 1:26 PM, Frank Cox thea...@melvilletheatre.com wrote:
On Tue, 24 Mar 2015 12:56:27 -0500
Les Mikesell wrote:
Doesn't anyone have a list of the oldest
kernel version for each Centos version you could be running and still
avoid known problems?
The best answer to your
On Wed, Mar 18, 2015 at 6:30 PM, Akemi Yagi amy...@gmail.com wrote:
On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer gordon.mess...@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
On Wed, Mar 18, 2015, at 18:30, Akemi Yagi wrote:
On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer gordon.mess...@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
On 03/19/2015 07:47 PM, Mark Felder wrote:
I just used the test script privided by RHEL
https://access.redhat.com/labs/leapsecond/leap_vulnerability.sh to test
my up2date CentOS 5 and CentOS 6 and all are reported as Non Vulnerable !
On Wed, Mar 18, 2015, at 18:30, Akemi Yagi wrote:
On Fri,
On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer gordon.mess...@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.
On Fri, Mar 6, 2015 at 4:04 PM, Gordon Messmer gordon.mess...@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.
Once upon a time, Les Mikesell lesmikes...@gmail.com said:
Helpful, 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?
Basically, POSIX time doesn't really handle leap seconds.
On Tue, Jan 20, 2015 at 3:27 PM, Michael Hennebry
henne...@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.
Once upon a time, Les Mikesell lesmikes...@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,
tzdata-java some_version?
Only way to prove
On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams li...@cmadams.net wrote:
Once upon a time, Les Mikesell lesmikes...@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
Les Mikesell wrote:
On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams li...@cmadams.net wrote:
Once upon a time, Les Mikesell lesmikes...@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
On Fri, Mar 6, 2015 at 1:50 PM, m.r...@5-cent.us wrote:
I don't think I need to 'prove' that computer programs do repeatable
things. I just want to know the version numbers that need to be
installed - something relatively easy to check.
snip
Two other thoughts: first, that it worked
Once upon a time, Les Mikesell lesmikes...@gmail.com said:
Now we know the issues, and hopefully someone had done the simulation
tests.
No, we know the issue that broke last time (2012), and a different issue
that broke the time before that (2008) (they were different problems).
We don't know
Once upon a time, Les Mikesell lesmikes...@gmail.com said:
On Fri, Mar 6, 2015 at 2:45 PM, Chris Adams li...@cmadams.net wrote:
So again, if you want to make sure there's no new issue, you'll have to
set up a test yourself. I doubt the 2008 or 2012 issues will happen
again, but there's
On Fri, Mar 6, 2015 at 2:26 PM, m.r...@5-cent.us wrote:
Every other sysadmin in the world got calls in the middle of the night
to fix their servers.
Ah, the system was fine, it was java that failed. And we've got a few
tomcat apps... but IIRC, we fixed them the next day - we're tier 3, and
On Fri, Mar 6, 2015 at 2:45 PM, Chris Adams li...@cmadams.net wrote:
So again, if you want to make sure there's no new issue, you'll have to
set up a test yourself. I doubt the 2008 or 2012 issues will happen
again, but there's plenty of room for new issues.
So are you saying that you think
On Fri, Mar 6, 2015 at 3:15 PM, Chris Adams li...@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
Les Mikesell wrote:
On Fri, Mar 6, 2015 at 1:50 PM, m.r...@5-cent.us wrote:
I don't think I need to 'prove' that computer programs do repeatable
things. I just want to know the version numbers that need to be
installed - something relatively easy to check.
snip
Two other thoughts: first,
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
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.
--
Michael henne...@web.cs.ndsu.nodak.edu
SCSI is NOT magic. There are *fundamental
-Original Message-
From: Les Mikesell
Sent: Thursday, January 15, 2015 12:36
On Thu, Jan 15, 2015 at 11:23 AM, Jason Pyeron
jpye...@pdinc.us wrote:
-Original Message-
From: Akemi Yagi
Sent: Thursday, January 15, 2015 12:05
snip/
Apparently Red Hat is well
-Original Message-
From: Akemi Yagi
Sent: Thursday, January 15, 2015 12:05
On Thu, Jan 15, 2015 at 8:43 AM, G Galitz ge...@galitz.org wrote:
Hi.
We have another leap second coming. Have past bugs with
Centos and leap
seconds (specifically high CPU spikes) been resolved?
On Thu, Jan 15, 2015 at 8:43 AM, G Galitz ge...@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:
On Thu, Jan 15, 2015 at 9:04 AM, Akemi Yagi amy...@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:43 AM, G Galitz ge...@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 Thu, Jan 15, 2015 at 11:23 AM, Jason Pyeron jpye...@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
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?
-G
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
On 01/16/2015 07:05 AM, Akemi Yagi wrote:
On Thu, Jan 15, 2015 at 9:04 AM, Akemi Yagi amy...@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:43 AM, G Galitz ge...@galitz.org wrote:
We have another leap second coming. Have past bugs with Centos and leap
seconds (specifically high CPU spikes) been
On Thu, Jan 15, 2015 at 3:00 PM, Rob Kampen
rkam...@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
-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of
Stephen Harris
Sent: Monday, July 02, 2012 6:24 PM
To: CentOS mailing list
Subject: Re: [CentOS] leap second
On Mon, Jul 02, 2012 at 11:09:41AM -0500, Les Mikesell wrote:
I'm sort
Hi Morgens,
Some java processes were 100% CPU after the leap second was added.
same problem here ... OpenNMS hat 100% CPU and didn't do anything anymore.
Rebooting is not necessary, though. For me it worked to just set the time
manually once, and everything was back to normal.
It doesn't
On Mon, Jul 2, 2012 at 11:02 AM, Keith Roberts ke...@karsites.net wrote:
I thought this was some sort of late April fools joke,
untill I read the article about ntpd on slashdot.
I'm sort of curious about how a bug of this magnitude slips through
the QA process (into java and RHEL, not CentOS).
Hi Keith,
My Centos 5.8 box is running ntpd, and I did not notice any
problems with it.
I did not have any problems on CentOS 5.8, but on one CentOS 6.2 box running a
Java application.
Kind Regards,
Peter.
___
CentOS mailing list
On Mon, Jul 02, 2012 at 11:09:41AM -0500, Les Mikesell wrote:
I'm sort of curious about how a bug of this magnitude slips through
the QA process (into java and RHEL, not CentOS). With all the furor
about y2k, did no one even bother to simulate a leap second ahead of
the real occurrence?
The
On Mon, Jul 2, 2012 at 11:24 AM, Stephen Harris li...@spuddy.org wrote:
On Mon, Jul 02, 2012 at 11:09:41AM -0500, Les Mikesell wrote:
I'm sort of curious about how a bug of this magnitude slips through
the QA process (into java and RHEL, not CentOS). With all the furor
about y2k, did no one
On Mon, 2 Jul 2012 18:11:25 +0200
Peter Eckel wrote:
I did not have any problems on CentOS 5.8, but on one CentOS 6.2 box running
a Java application.
I had problems with Firefox on four computers running fully updated Centos 6.
Firefox was suddenly taking up a lot of CPU power showing nothing
Hi Les,
Interesting, but I thought that ntp clients always advanced the clock
by small fractions of a second anyway even when the master source
differs by more.
they do. But the leap second is quite a different thing: Actually the time
doesn't really diverge from the server's, but the
On Mon, Jul 2, 2012 at 1:32 PM, Gordon Messmer yiny...@eburg.com wrote:
On 07/02/2012 09:24 AM, Peter Eckel wrote:
On the other hand I'm a bit surprised that the problems were
comparably few - actually there is a time '01:59:60' for one second,
and any plausibility check I've ever seen assumes
On 07/02/2012 10:37 AM, Peter Eckel wrote:
they do. But the leap second is quite a different thing: Actually the
time doesn't really diverge from the server's, but the stratum 1
server deliveres a totally unexpected 01:59:60, and the stratum 2
server follows.
That's not quite correct. The
On 07/02/2012 12:54 PM, Les Mikesell wrote:
Sooo... Are the 6.x boxes that did not exhibit a problem yet still
likely to have it if you start a threaded program or did it have to
happen in the 1 second window?
As far as I know, it could still pop up. The futex handling in the
kernel will be
On 7/2/2012 10:24 AM, Peter Eckel wrote:
... and leap seconds are not even scarce.
An event on an unpredictable schedule averaging 1.7 years since 1972
doesn't count as scarce?
That's the answer to Les's outrage, too, by the way. Might as well
expect the JRE to have code to deal with cosmic
On 7/2/2012 2:06 PM, m.r...@5-cent.us wrote:
Dumb question, but I haven't followed this thread that closely - been busy
at work - but why not
$ service ntp stop
$ ntpdate
$ service ntp start
Because that results in a call to adjtimex(2), which is also the syscall
used by ntpd, which
- Kernel Begin
1 Time(s): Clock: inserting leap second 23:59:60 UTC
-- Kernel End -
hee hee.
gotta love it
___
CentOS mailing list
On 7/1/2012 10:07 AM, Mogens Kjaer wrote:
On 07/01/2012 03:05 PM, Bob Hoffman wrote:
- Kernel Begin
1 Time(s): Clock: inserting leap second 23:59:60 UTC
-- Kernel End -
hee hee.
gotta
From: bob b...@bobhoffman.com
To: CentOS mailing list centos@centos.org
Sent: Sunday, July 1, 2012 9:55 AM
Subject: Re: [CentOS] leap second
On 7/1/2012 10:07 AM, Mogens Kjaer wrote:
On 07/01/2012 03:05 PM, Bob Hoffman wrote:
- Kernel Begin
47 matches
Mail list logo
