I think this fits:
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
Em 30/06/12 19:47, Antonio M. Moreiras escreveu:
I had two odd events today, just after midnight (utc).
My nagios monitoring went crazy (all servers really ok, but
On Jun 30, 2012, at 17:58, Ask Bjørn Hansen wrote:
Looks like about 250 servers missed the leap second.
This query counts how many servers had an offset 100ms around one
second off. It was basically none yesterday, and 253 in the first
hour after the leap.
Compared to the last leap
Hi,
On my two linux-boxes I've got this in my logs:
Box 1: Jul 01 01:59:59 [kernel] [11613806.049909] Clock: inserting leap
second 23:59:60 UTC
Box 2: Jul 01 01:59:59 [kernel] [976439.291563] Clock: inserting leap second
23:59:60 UTC
(I'm on UTC+2)
That's the only thing in my logs I could
Hello Antonio
On 01.07.2012 00:47, Antonio M. Moreiras wrote:
I had two odd events today, just after midnight (utc).
My nagios monitoring went crazy (all servers really ok, but alarming on
nagios). I think some regular expression in the ntp monitoring plugin
didn't like some new response
Hi there,
On Sun, 1 Jul 2012, Martin Schr?der wrote:
I recently upgrade my old debian server to the latest stable ntpd.
It crashed promptly at the leap second. :-(
How old is 'old'?
I manage a couple of dozen Debian servers. All are fully up to date
Squeeze, running some variety of ntpd
On Sun, Jul 1, 2012 at 09:08 UTC, David J Taylor wrote:
- The Windows PCs fed from either Garmin GPS 18/x LVC or Sure Electronics
GPS boards appear to have reset some 17..24 minutes after 00:00, suggesting
they were using the GPS for the time (as well as the precise edge), and the
GPS devices
In light of David's report and looking at my own similar Windows ntpd
+ PPS GPS setup, I retract my nuanced comments about his offset
graph, because I now believe ntpd on Windows misapplied the leap
second completely. The code scheduled it perfectly, relayed the info
on to clients correctly, then
-Original Message-
From: Dave Hart
Sent: Sunday, July 01, 2012 3:18 PM
[]
Your offset graphs tell a slightly more nuanced picture which fits my
expectations. ntpd slewed the clock 1s back over 2s near midnight UTC
as expected, regardless of what its sources told it, because it knew
the
Was it advertising leap=01 before the leap ?
It might be because it leaped backwards (would be strange, though : no
backward leap was ever introduced in the leapfile, IIRC)
2012/7/1 AlbyVA alb...@empire.org:
It looks like my server picked up the Leap Second, but it just counted
19:59:59
Yeah it was showing Leap=01 before. My guess is that it just did :59 twice
rather than :59 then :60.
I doubt it leap'd backwards, since there was an added second by doing :59
twice. Had it leap'd backwards,
I assume it would have gone :58 - :00, thus removing a second of time.
On Sun, Jul 1,
On Sun, Jul 1, 2012 at 11:15 UTC, AlbyVA wrote:
It looks like my server picked up the Leap Second, but it just counted
19:59:59 twice.
Check it out: (NOTE: EDT -0400 Timezone).
Sat, Jun 30 2012 19:59:59.387
Sat, Jun 30 2012 19:59:59.894
Sat, Jun 30 2012 19:59:59.401
Sat, Jun 30 2012
Yes, my bad. I inverted backwards and forwards :-(
2012/7/1 AlbyVA alb...@empire.org:
Yeah it was showing Leap=01 before. My guess is that it just did :59 twice
rather than :59 then :60.
I doubt it leap'd backwards, since there was an added second by doing :59
twice. Had it leap'd backwards,
Hi,
Many systems still generate v1 uuids (
http://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28MAC_address.29
-
for example still used by MySQL by default ) and seeing how most OSes are
handling the leap second is kind of worrying me, since it greatly increases
the risk of
Fabian Wenk kirjoitti:
Could be some kind of device (e.g. access routers) which are mostly
deployed in Turkey and using the Pool to sync, which show this behavior
during the leap second day.
That's the best theory we have at the moment.
But here you have the same short peaks which I have
14 matches
Mail list logo
