Leap Second Bug Causes Crashes

All of my servers were fine by Anonymous Coward · 2012-07-01 08:03 · Score: 5, Insightful

And I didn't do anything special, just kept their software up-to-date.

Re:All of my servers were fine by Sir_Sri · 2012-07-01 08:05 · Score: 4, Informative

That can be hard for some people.
Re:All of my servers were fine by Anonymous Coward · 2012-07-01 08:10 · Score: 3, Informative

Agreed. Patches that aren't required to solve an ongoing incident impacting customer traffic require about 2 weeks advance notice to pass through change control, and that's if everything is perfect. A single error in a ticket can push that ticket out another week, and another, and so on.
Generally, we shoot for 3 weeks before we are allowed to install a patch. On average, it's about right.
Re:All of my servers were fine by Anonymous Coward · 2012-07-01 08:15 · Score: 5, Informative

the patch was posted back in March.
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d
Re:All of my servers were fine by 0123456 · 2012-07-01 08:55 · Score: 2

One of ours (running Java on Linux) started throwing out NTP alarms at 10 seconds after midnight, but it seems to have stayed up. However, the software on that particular system is especially vulnerable to leap second issues so we'd tested it pretty well beforehand.
Otherwise no-one has complained about any other systems going down so I presume they're OK.
Re:All of my servers were fine by nmb3000 · 2012-07-01 09:26 · Score: 4, Insightful

And I didn't do anything special, just kept their software up-to-date.
That's a nice ideal, but the reality is that many up-to-date "stable" distribution releases are still using kernels which are susceptible the leap second problem (and haven't had the patch back-ported to them). Ubuntu 8.04 LTS server is supposed to be supported until April 2013, and on my (updated!) system,
# uname -r 2.6.24-28-server
I like the idea of stable releases, but this is a glaring problem with the entire idea. Everyone extolls the wondrous virtues of package managers for Linux-based systems, but the dirty secret is that unless you stay bleeding-edge (which is usually the opposite of "server"), you'd better be happy with the 4-year old version of Apache, PHP, MySQL, and the Linux kernel you're running. Sure, it's possible to manually download and install packages from a newer release (assuming you can get past the dependency hell usually associated with it). Sure, it's possible to try and splice in (or "pin" packages using Debian parlance) from a newer repository. Sure, it's possible to install from source, compiling and installing everything by hand. But once you do any of these you've given up 90% of what makes the package manager useful and are just asking for dependency problems in the future.
And, all that aside, do you even know if the patch released to fix this problem is included in your distribution-released kernel? If you're not rolling your own kernel it can be nigh to impossible to know what's included and what's not -- in that case it doesn't even matter if it's up-to-date.

--
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Re:All of my servers were fine by lister+king+of+smeg · 2012-07-01 09:50 · Score: 3, Informative

And, all that aside, do you even know if the patch released to fix this problem is included in your distribution-released kernel? If you're not rolling your own kernel it can be nigh to impossible to know what's included and what's not -- in that case it doesn't even matter if it's up-to-date.
Well you could read through the change log and release notes to find out.

--
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Re:All of my servers were fine by RNLockwood · 2012-07-01 10:42 · Score: 2

NASA's Astronomy Picture of the Day, http://antwrp.gsfc.nasa.gov/apod/astropix.html, has apparently been down all day; wonder if this is the cause.
Anyone heard from the Space Lab today?

--
Nate
Re:All of my servers were fine by thePowerOfGrayskull · 2012-07-01 10:42 · Score: 3, Interesting

Our problem was with a third party monitoring solution - its daemon process brought every single one of our servers to a near halt by consuming all available cpu cycles at the stroke of gmt midnight.
The OS itself was fine.
This monitoring software is common enough that it likely was behind a lot of the issues seen around the 'net.
Re:All of my servers were fine by Ruie · 2012-07-01 11:19 · Score: 2

All *.gsfc.nasa.gov sites I tried to access are down - Fermi data, some catalogs, etc.
Re:All of my servers were fine by Guy+Harris · 2012-07-01 11:47 · Score: 4, Informative

Our problem was with a third party monitoring solution - its daemon process brought every single one of our servers to a near halt by consuming all available cpu cycles at the stroke of gmt midnight.
The OS itself was fine.
Well, if you're talking a Linux kernel, the part of the OS that dealt with leap seconds was not OK, and was "not OK" in a fashion that could cause processes using futexes to spin and consume all available CPU cycles when a leap second is introduced.

This monitoring software is common enough that it likely was behind a lot of the issues seen around the 'net.
...perhaps by virtue of either using futexes (in what I'm presuming is a legitimate fashion) or using something that uses futexes.
Re:All of my servers were fine by Gil-galad55 · 2012-07-01 12:26 · Score: 5, Informative

They lost commercial power due the big storm system that went through the DC area.

--
To follow knowledge like a sinking star, / Beyond the utmost bound of human thought. ("Ulysses", Tennyson)
Re:All of my servers were fine by Guy+Harris · 2012-07-01 12:54 · Score: 2

That's a nice ideal, but the reality is that many up-to-date "stable" distribution releases are still using kernels which are susceptible the leap second problem (and haven't had the patch back-ported to them).
To which of the, apparently, two or more leap second problems are you referring? (The latest one, causing the bogus futex timeouts and subsequent CPU-eating spinfests, is, apparently, having a fix developed today, July 1, 2012, so getting that patched would be a little difficult - especially getting it patched before the leap second is introduced. :-))
Re:All of my servers were fine by Tough+Love · 2012-07-01 13:39 · Score: 2

That can be hard for some people.
And also not necessary on Linux, with the exception of security updates. Even my machines with ancient images like Ubuntu 8 where completely unbothered. Probably you're ok with any Linux younger than 25 years. Most probably, Linux 2.0 would have been fine except for the security update question.

--
When all you have is a hammer, every problem starts to look like a thumb.
Re:All of my servers were fine by rlseaman · 2012-07-01 14:57 · Score: 2

NASA Goddard is near Baltimore. They lost power in the storm and are operating under "Code Red": http://www.nasa.gov/centers/goddard/
Quite likely other misbehavior blamed on the leap second is actually the result of the storm (or like Pirate Bay, some unrelated crash).
Re:All of my servers were fine by jaymemaurice · 2012-07-01 15:49 · Score: 2

pesky software engineers, writing code for no reason.

--
120 characters ought to be enough for anyone
Re:All of my servers were fine by tehcyder · 2012-07-02 01:12 · Score: 2

Nice, huh? No wonder that 1/3 of the traffic on the internet is served from FreeBSD (data base on Netflix being a FreeBSD house and that they account for 1/3 of the internet's traffic).
But I thought that Netflix confirms BSD is dying?

--
To have a right to do a thing is not at all the same as to be right in doing it
Re:All of my servers were fine by Tough+Love · 2012-07-02 06:08 · Score: 2

No question there was a kernel bug, a race condition to be precise. Now fixed. The chance of hitting it is pretty small, but if you have enough servers or the right load, some of them will. Kernel hang was possible but livelock with high CPU was more likely. The workaround: set the time.
The chance of your home server hitting this was vanishingly small. You're more likely to get a power outage.

--
When all you have is a hammer, every problem starts to look like a thumb.

Re: by bleedingsamurai · 2012-07-01 08:05 · Score: 2

Interesting. I wonder what conditions had to have been met for a crash to happen, none of my servers had so much as a hick-up.

Linux by Anonymous Coward · 2012-07-01 08:08 · Score: 4, Informative

I'm a Linux admin at a fairly large hosting company. The only thing that I personally aware of happening this time around was that the time change triggered a bug in the OpenManage software on Dell servers causing it to use 100% CPU. The solution was to resync the time and restart OpenManage. It wasn't really a fault of Linux itself, but in OpenManage on Linux. Lots of datacenters use Dell hardware and I'm sure most use OpenManage, so I'm sure the problem was widespread.

Re:Linux by Anonymous Coward · 2012-07-01 08:21 · Score: 5, Informative

What you describe is a bug in the Linux kernel that causes problems for the Java VM that OpenManage uses.
It is not a bug in OpenManage at all.
Re:Linux by X0563511 · 2012-07-02 01:51 · Score: 2

It blew up Virtualbox for me as well. Guests were eating 100% CPU even though they were not aware of it, and after killing them the CPU load transferred to another Virtualbox service. Odd.
Reboot and it was working normally again.

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...

Re: by Anonymous Coward · 2012-07-01 08:10 · Score: 5, Funny

>hick-up.

The hick up watching the servers when the leap second came was you.

Our Red Hat servers had no issues at all by 93+Escort+Wagon · 2012-07-01 08:12 · Score: 4, Insightful

I'm uncertain why these reports keeps referring to some monolithic "Linux" that is supposed to have had issues - Red Hat's the biggest Linux vendor, and certainly their "Linux" handled it just fine.

What distros had issues?

--
#DeleteChrome

Re:Our Red Hat servers had no issues at all by Nutria · 2012-07-01 08:22 · Score: 4, Informative

TFA mentioned that the RHE6 kernel had the bug, but not RHE5.
It appears also that system load was a big factor, so if your systems aren't busy on Saturday then they might not have crashed even if running an affected kernel.

--
"I don't know, therefore Aliens" Wafflebox1
Re:Our Red Hat servers had no issues at all by Anonymous Coward · 2012-07-01 08:44 · Score: 4, Informative

Red Hat had a lot of issues.
https://access.redhat.com/knowledge/articles/15145
https://access.redhat.com/knowledge/solutions/154713
It depended entirely on your load. The buggy kernal code ran every 17 minutes for the 24hr period leading up to the leap-second insertion.
If you had enough load, your chance of dead-locking your system increased significantly.
Solution, strip the leap-second flag by manually setting your time.
Re:Our Red Hat servers had no issues at all by MightyMartian · 2012-07-01 08:45 · Score: 4, Funny

Sorry can't remember the name. It's the one that takes the credit for the work of others.
Windows?

--
The world's burning. Moped Jesus spotted on I50. Details at 11.
Re:Our Red Hat servers had no issues at all by drinkypoo · 2012-07-01 08:49 · Score: 4, Funny

Sorry can't remember the name. It's the one that takes the credit for the work of others.
You must be talking about SCO, but if you're still running CND you should probably upgrade.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Our Red Hat servers had no issues at all by Phroggy · 2012-07-01 11:37 · Score: 2

I've got a Slackware 12.0 box running 2.6.21.5 that crashed. Slackware 12.1 (2.6.24.5) and 12.2 (2.6.27.31) did not crash, but it sounds like these versions are vulnerable as well, I just got lucky.

--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Re:Our Red Hat servers had no issues at all by Guy+Harris · 2012-07-01 19:10 · Score: 2

The bug is related to kernel version, IIRC (introduced somewhere in the 2.6 series, resolved in 3.2 or somesuch). So it depends what kernel the distros ran.
More like resolved yesterday (today being July 2, 2012 where I'm typing this).

What about Windows and Mac? by kthreadd · 2012-07-01 08:13 · Score: 4, Interesting

So far all I've heard about is affected Linux systems, did Windows and OS X just fine?

Re:What about Windows and Mac? by Nutria · 2012-07-01 08:27 · Score: 2

And apparently neither did any desktop Linux systems.

--
"I don't know, therefore Aliens" Wafflebox1
Re:What about Windows and Mac? by Guy+Harris · 2012-07-01 09:39 · Score: 2

So far all I've heard about is affected Linux systems, did Windows and OS X just fine?
The glitch mostly affected POSIX compliant operating systems as POSIX specifies a day as 86400.
So you're saying the glitch could affect OS X (or, at least, OS X Snow Leopard - although Leopard was also registered - but I'll bet Lion behaves, and Mountain Lion will behave, the same way)?
Re:What about Windows and Mac? by Guy+Harris · 2012-07-01 10:46 · Score: 4, Informative

My guess ist that Windows simply ignored it, so there never was a 61st second in a minute.
Well, if Microsoft's documentation of the SYSTEMTIME structure reflects the implementation, GetSystemTime() , the claim in that man page^W^WMSDN page that "The system time is expressed in Coordinated Universal Time (UTC)" nonwithstanding, cannot acknowledge the existence of a 61st second in a minute ("The second. The valid values for this member are 0 through 59.", as the SYSTEMTIME page says).
But, just as on UN*X, you have "counter" and "human-style label" times (time_t, struct timeval, struct timespec are examples of the former, and a struct tm as returned by, for example, gmtime() is an example of the latter, on UN*X), with the Windows versions of those being SYSTEMTIME and FILETIME respectively. That page on FILETIME says nothing about leap seconds - does it just keep counting over a positive leap second or does it stop or what? And, if it doesn't just keep counting over a positive leap second, does it just freeze for a while second, or does it slow down over some period of time so that it eventually syncs up, or what?
As for NTP, Microsoft has a page on "How the Windows Time service treats a leap second", which says

When the Windows Time service is working as a Network Time Protocol (NTP) client
The Windows Time service does not indicate the value of the Leap Indicator when the Windows Time service receives a packet that includes a leap second. (The Leap Indicator indicates whether an impending leap second is to be inserted or deleted in the last minute of the current day.) Therefore, after the leap second occurs, the NTP client that is running Windows Time service is one second faster than the actual time. This time difference is resolved at the next time synchronization.
(the author of which needs to be told what "inserted or deleted" implies - do they mean that, regardless of whether a leap second is inserted or deleted, the NTP client that is running Windows Time service is one second faster than the actual time?)
And then there's one more question: if there's anything in the NT kernel that deals with leap seconds, does any version have a glitch, as some versions of the Linux kernel do?
If not, then many of the other problems might not exist on Windows. This email from John Stultz, the author of the fix linked to in the previous paragraph, seems to indicate that at least some of the problems, if not all of them, stem from a kernel bug, so it might be that Java and company might be Just Fine on systems that don't have a kernel glitch of that sort (so they might work fine on at least some non-Linux systems, as well as on Linux systems with the bug fixed).
Re:What about Windows and Mac? by Guy+Harris · 2012-07-01 11:37 · Score: 3, Interesting
As far as I can tell, all current operating systems handled it fine. It's applications that have problems, mainly server-type apps that actually use the clock for important things.
Linux being heavily affected is just a side-effect of most servers running Linux (although apparently some older versions don't handle leap seconds so cleanly - maybe that has something to do with it?).
Yes, at least one of the problems appears to be a Linux kernel problem. However, as that thread indicates, the consequence of this isn't a kernel crash; it causes futexes to repeatedly time out (or, at least, causing futexes with timeouts to repeatedly time out). I'm guessing, perhaps incorrectly, that this might mean that code waiting for a futex gets a kernel wakeup due to a timeout, checks whether the condition being waited for has happened, discovers that it hasn't, sleeps in the futex again, gets a kernel wakeup due to a timeout, checks whether the condition being waited for has happened, discovers that it hasn't, sleeps in the futex again, lathers, rinses, repeats, so it makes no progress and chews up tons of CPU.
If so, then:
- this particular problem is specific to systems running Linux kernels with the problem (and hence specific to Linux);
- applications that don't themselves have issues with leap seconds might be affected by this;
so Linux being heavily affected might also be a side-effect of, well, some versions of the Linux kernel having a bug that's triggered by leap seconds.
However, unless an application happens to use futexes in a fashion that trips over the bug, they won't be affected. It might be server applications that are most likely to do so, meaning that you might not see it on, say, a desktop or handheld Linux machine, or even on some servers.
Re:What about Windows and Mac? by magamiako1 · 2012-07-01 13:45 · Score: 3, Informative

In an Active Directory domain, the computer with the FSMO PDC Emulator role is not only a proper NTP server, but you can sync your devices to it.

Also, look up the command: w32tm

Extremely weird by Anonymous Coward · 2012-07-01 08:18 · Score: 5, Informative

From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Affects Debian stable a lot.

Affects Java and Virtualbox (starts using too much CPU).

Affected my browser (iceweasel on debian testing).

Affects SOME mysql installs (5.1 and 5.5, but not all, and of two identical installs one might be affected, the other not).

The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start

(I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

Re:Extremely weird by burne · 2012-07-01 09:09 · Score: 4, Informative

It's a race-condition, either crashing your ancient kernel or causing software using certain kernel-calls to effectively lock up. In both cases load seems to be a factor.
Over here the race-condition coincided with the actual leap-second and the start of the first batch of cronjobs at 02:00 local time.

(I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)
Bad idea. It would have prevented kernels affected by the race-condition from crashing, but would have meant most of your running software would have been either hit by this bug or would have been on the mercy of a 17 year old pimple-faced coder.
I think I prefer a crash over the mayhem caused by banking-software not handling a leap-second correctly. That could bankrupt whole countries.
Re:Extremely weird by Guy+Harris · 2012-07-01 12:21 · Score: 2

From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:
There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d
I don't think that's the issue. The issue discussed in this lklm thread is a different issue with, presumably, a different John Stultz fix.

The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start
Presumably meaning "workaround" rather than "fix".

(I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)
Sounds good to me, but I thought that was a good idea back in the late '80's; the POSIX people thought otherwise, so....
At least as I read RFC 5905, time stamps in NTP packets are essentially "simple counters", and count positive leap seconds and don't count seconds removed with negative leap seconds. I'm not sure what an NTP implementation is supposed to do with the "leap indicator"; that might be dependent on what sort of time the system is supposed to provide to applications. I don't know whether the Linux kernel giving a damn about leap seconds is due to it trying to supply "POSIX time", i.e. time represented as "seconds since the Epoch" rather than as the number of seconds that have elapsed since the Epoch (yes, the two are different), or if it has to do that to function as an NTP client.

Re:Linux kernel unable to cope? I think not. by Anonymous Coward · 2012-07-01 08:33 · Score: 4, Informative

There was a Linux kernel bug. See
http://news.ycombinator.com/item?id=4183122
http://marc.info/?l=linux-kernel&m=134110635328824&w=2
and
https://lkml.org/lkml/2012/6/30/122

Dreaded S60 bug... by mschaffer · 2012-07-01 08:35 · Score: 2

It's like the Y2K bug, but every few years.

Re: by Anonymous Coward · 2012-07-01 08:39 · Score: 2, Informative

The hard system lock bug due to a leap second was patched in 2.6.29, so either you've got some weird related bug, or something is very wrong.

Re:Why now? by Znork · 2012-07-01 08:41 · Score: 2, Interesting

We will keep having these kinds of issues for as long as some people who fail to understand that time of day is an arbitrary number whose main utility lies in it being composed of predictable periods and divided into homogenous units. It should have no relation whatsoever to whatever time the sun happens to rise or set at any particular location and above all it should not be changed to accomodate fluctuations in the orbit of a rock circling an arbitrary star. Abominations like leap seconds or daylight savings make the whole system less useful by merely existing.

But personally I wouldn't be surprised if people off the equator were to get summer minutes composed of 120 seconds during daytime (or even better, a scale!) to ensure the sun rises and sets at the same time year around. Or, hey, why not simply make the seconds longer? Or a combination of both plus we can define pi to be 3 to make things simpler.

Re: by Admiral+Justin · 2012-07-01 08:47 · Score: 2

Configuration of the system to only accept 23:59:59 and not 23:59:60

--
You will be baked, and there will be cake.

You probably don't do much Java, then by burne · 2012-07-01 08:51 · Score: 5, Informative

As it turns out my biggest problems was customer-supplied software which uses their own java jre's. We install a jre by default and update it whenever possible, but some software (Adeptia, VLTrader, Alfresco) comes with their own ancient jre and scripts to call that over system-supplied java.

Not a single machine crashed (we are very explicitly in charge of what OS-version there's running) but a lot of java locked up and had to be restarted.

I can even see a small bump in the power-usage around two o' clock (0:00 GMT).

Re:You probably don't do much Java, then by thegarbz · 2012-07-01 11:42 · Score: 4, Funny

I can even see a small bump in the power-usage around two o' clock (0:00 GMT).
Leap seconds contribute to global warming. We need to raise this at the next G8 summit.
Re:You probably don't do much Java, then by Guy+Harris · 2012-07-01 11:43 · Score: 4, Informative

So are you saying that, in addition to the Linux kernel glitch in question (which appears to cause some userland processes to spin)
Actually, I'm not sure that's the case. John Stultz's mail from July 1, 2012 speaks of a bug where clock_was_set() wasn't called after the leap second was added, and of a patch he was working on, so the bug in question might not have been fixed in March.
Re:You probably don't do much Java, then by Lennie · 2012-07-01 14:04 · Score: 2

Looked to me like it was only 64-bit Java, not 32-bit Java

--
New things are always on the horizon
Re:You probably don't do much Java, then by archont · 2012-07-01 23:51 · Score: 3, Informative

What is this, 1990? All modern CPUs have protection against overheating and disabling that protection requires, at the very least, some crafty soldering or flashing a 3rd party BIOS. If you're capable enough to do that you're probably running some sci-fi prototype rig from the future using pressurized mercury phase transition cooling or something.
So no, I don't see how any properly set-up rig can make the CPU cook itself.

Re:FUD? by burne · 2012-07-01 08:59 · Score: 2

Now that Linux hit the same type of hurdle, we're all of a sudden being very nuanced about the definition of code quality? Typical.

Wow. You're still pissed over Azure failing, your Xbox disabling itself, your Zune crashing for a full day and your Outlook manhandling your appointments (on more than one occasion)?

Talk about carrying a grudge..

I always thought leap seconds were stupid by circletimessquare · 2012-07-01 09:08 · Score: 2, Interesting

Why not bundle them and apply them every 10 or 20 years?

And apparently I'm not alone:

http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds

Hogwash, Astronomers can find coping mechanisms, it's either that or these ridiculous levels of stress for systems admins.

--
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it

Re:I always thought leap seconds were stupid by burne · 2012-07-01 09:19 · Score: 2

Hogwash, Astronomers can find coping mechanisms, it's either that or these ridiculous levels of stress for systems admins.
TAI doesn't know about leapseconds, and it's the coping mechanism of choice for astronomy.
Re:I always thought leap seconds were stupid by at10u8 · 2012-07-01 11:01 · Score: 3, Interesting

except that BIPM, the providers of TAI, have published this http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf wherein the CCTF "stresses that TAI is the uniform time scale underlying UTC, and that it should not be considered as an alternative time reference." This appears to indicate that the CCTF and BIPM are not comfortable with the notion that operational systems might be employing TAI as their time scale. At the end of that paper they also discuss the possibility that TAI could cease to exist.
Re:I always thought leap seconds were stupid by thue · 2012-07-01 11:09 · Score: 4, Insightful

> Why not bundle them and apply them every 10 or 20 years?
The problem we have here is that leap seconds are rare. Things that are common are tested for, and quickly found if broken. Having something which only happens every 20 years is a recipee for disaster every 20 years.
My view is that NTP is at fault, because the 61th second is a brittle way to handle it. NTP should use the same method as google for smearing the leap second out over fx an hour: http://googleblog.blogspot.dk/2011/09/time-technology-and-leaping-seconds.html

Re:Why now? by vux984 · 2012-07-01 09:09 · Score: 4, Insightful

and above all it should not be changed to accomodate fluctuations in the orbit of a rock circling an arbitrary star.

That is precisely the point of keeping track of the time of day, or day of the year.

time of day is an arbitrary number whose main utility lies in it being composed of predictable periods and divided into homogenous units.

You do not need a complex system like date time comprised of minutes hours, seconds, months, weeks, and years if you just want to measure time in a convient homogenous unit then define a time-zero, and just count milliseconds from that to whatever arbitrary distance into the past and future you want from that. Measure it kilo-seconds, mega-seconds, giga-seconds... etc.

The entire point of date/time is because we do in fact care a lot about how that "arbitrary counter" lines up with when we will be awake or asleep or eating at various points -- that's what makes it useful.

What we should have is what I've described above, time-zero and a counter. And translations from that to localized date time should be handled by a library.

Re:Linux kernel unable to cope? I think not. by Anonymous Coward · 2012-07-01 09:09 · Score: 5, Interesting

I run Arch Linux with kernel 3.4.4 and it went haywire. My machine was very heavily loaded at the time and when the leap second happened mysqld, firefox, and ksoftirq processes started consuming 100% CPU. The load factor was well over 10 and the machine was grinding along. It didn't actually fail but it was loaded down.

Even restarting the processes didn't fix it. The high load would go away once I stopped the processes but as soon as I started them again the load would come right back. I had Firefox open on a blank page not doing anything and it was slammed at 100% CPU and had a could ksoftirq tasks slammed at 100% CPU each too.

I had to reboot the machine to get it back to normal.

I have Ubuntu and Debian servers that for whatever reason did not add the leap second so they were fine. Their time was a second off today though (at least until ntp slowly corrected it or I manually intervened).

Only Linux affected? by cpghost · 2012-07-01 09:15 · Score: 4, Interesting

I'm managing a cluster of 2,400 nodes running FreeBSD, and AFAICS, none was tripped off by leap second NTP adjustments. On the other hand, 4 out of 180 Linux nodes crashed simultaneously at that very moment. All this is exceedingly weird, but may indeed point to a subtle bug in the Linux kernel (only?). I've never witnessed this behavior in the past.

--
cpghost at Cordula's Web.

Re:Only Linux affected? by Guy+Harris · 2012-07-01 12:37 · Score: 2

I'm managing a cluster of 2,400 nodes running FreeBSD, and AFAICS, none was tripped off by leap second NTP adjustments. On the other hand, 4 out of 180 Linux nodes crashed simultaneously at that very moment. All this is exceedingly weird, but may indeed point to a subtle bug in the Linux kernel (only?)
Could be, if "crashed" means "had some processes start spinning like mad". If it was a kernel-mode crash, that might be another bug.

Debian + Java = Issues by thatskinnyguy · 2012-07-01 09:17 · Score: 2

About 5 seconds after midnight GMT a Java server app running on my Debian Squeeze server decided it was going to eat-up ALL THE THINGS and for some reason, the server rebooted itself. Glad to know I wasn't alone in shitting myself over odd behaviours.

--
The game.

Re:FUD? by kasperd · 2012-07-01 09:43 · Score: 4, Funny

Actually I didn't realize I was affected by this bug until a few minutes ago, when I used strace to see why firefox was using up all the time on one of my cores.

You don't need a leap second in order for that to happen. Firefox does that regularly.

--

Do you care about the security of your wireless mouse?

Google on how they fixed that.. by Barryke · 2012-07-01 09:43 · Score: 3, Interesting

Google official blog: "Time, technology and leaping seconds" (sept 2011)
http://googleblog.blogspot.in/2011/09/time-technology-and-leaping-seconds.html

I wonder if the leap second has anything to do with the labs Chubby paper / site currently being offline..

--
Hivemind harvest in progress..

Re:Linux kernel unable to cope? I think not. by kwardroid · 2012-07-01 10:12 · Score: 5, Informative

Restarting ntp wasn't enough for me, I had to reset the date with:
date -s "`date`"
Only one machine went haywire though.

Re:FUD? by dotgain · 2012-07-01 10:17 · Score: 2

Have you read the source for /bin/sh ?

Re:Why now? by Guy+Harris · 2012-07-01 11:24 · Score: 4, Funny

What we should have is what I've described above, time-zero and a counter. And translations from that to localized date time should be handled by a library.

Which, sadly, POSIX doesn't let you have as "UNIX time":

4.15 Seconds Since the Epoch
A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds ( tm_sec ), minutes ( tm_min ), hours ( tm_hour ), days since January 1 of the year ( tm_yday ), and calendar year minus 1900 ( tm_year )) is related to a time represented as seconds since the Epoch, according to the expression below.
If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec , tm_min , tm_hour , tm_yday , and tm_year are all integer types:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - (tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.
How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
Note:
The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient.

If there were a UN*X API to get a count of seconds since the Epoch (in addition to, or instead of, a call to get "seconds since the Epoch"), and a UN*X API to convert those to UTC and local time labels, that would get what you want. Modulo making it work with NTP, the former could be implemented with less difficulty than a call to get "seconds since the Epoch", and the latter is called "the Olson code complete with the leap seconds database".

However, that would then require some mechanism to allow code to schedule something to happen at a given UTC label; simply calculating the UNIX time for that UTC label, getting the current UNIX time, and scheduling it for then-now seconds in the future is insufficient, as the UNIX time for a given UTC label in the future might change if a leap second is scheduled between then and now. (Note that if you support scheduling something to happen at a given local civil time label would already require correction of that sort to handle DST rule changes.) This would also have to do something if you schedule an event for YYYY-DD-MM 23:59:59 and a negative leap second occurs so that there is no 23:59:59 on YYYY-DD-MM; "something" might be "let somebody know and ask them to correct it" or "do it at 00:00:00 on the next day", perhaps depending on the reason why it's scheduled.

Re: by Guy+Harris · 2012-07-01 11:51 · Score: 3, Interesting

The hard system lock bug due to a leap second was patched in 2.6.29, so either you've got some weird related bug, or something is very wrong.

Well, the weird related bug would arguably count as something being wrong. Apparently there is a bug in the handling of the insertion of positive leap seconds that could cause weird behavior with futexes, and that bug appears not to have been fixed until at least July 1, 2012 (I'm guessing John Stultz has worked up a patch).

Re:Why now? by Guy+Harris · 2012-07-01 11:54 · Score: 2

Considering leap-seconds happen every now and then, it seems odd that such fundamental things as Linux and Java can not handle it. AFAIK, it was just about for years ago since we last had a leap-second.

Perhaps the bug that was mentioned in the lkml thread that started with this message was introduced less than four years ago, so the code in question had never gotten exposed to a leap second except perhaps in testing (I don't know how hard it is to reproduce it; John Stultz wasn't initially able to reproduce it in his testing, but eventually succeeded).

Re:FUD? by Guy+Harris · 2012-07-01 12:08 · Score: 3, Informative

The bug has already been fixed for months now

A bug might have been fixed for months now, but I don't think that's the bug here.

Re:FUD? by Guy+Harris · 2012-07-01 12:10 · Score: 2

the difference being this bug was patched already it only affected systems the were not kept up to date.

A bug, perhaps. This bug, perhaps not.

Re: by AmberBlackCat · 2012-07-01 12:34 · Score: 2

If that actually happened, then they should have just made it do 23:59:59 twice instead of crashing all the computers. I would like somebody to give me a concrete reason why any computer system should actually crash because of a lost second.

Please read this lkml thread before commenting by Guy+Harris · 2012-07-01 14:42 · Score: 3, Informative

This linux-kernel mailing list thread discusses a kernel bug that causes futexes to repeatedly time out, so that code using them (which might include POSIX mutexes and condition variables, if that's what glibc uses for them on Linux) might spin.

That's not the kernel-leap-year-handling bug that was fixed back in March, so it's not as if a properly-patched kernel wouldn't get hit by this (unless you define "properly-patched" as "includes the patch John Stultz came up with on July 1, 2012").

So, yes, this particular bug is Linux-specific (i.e., there's a reason why it hit Linux servers), and might not be the fault of the userland code running atop it (so it might not, for example, be Java's fault).

Re:Linux kernel unable to cope? I think not. by Rakarra · 2012-07-01 19:45 · Score: 2

Mods -- please mod this up to a thousand. kwardroid's fix fixed this for all the affected machines I've found so far.

What did the computers do with that extra second? by RivenAleem · 2012-07-01 19:55 · Score: 2

Data: She brought me closer to humanity than I ever thought possible, and for a time...I was tempted by her offer.
Jean-Luc Picard: How long a time?
Data: Zero point six eight seconds, sir. For an android, that is nearly an eternity.

Re:I agree... by cmdrbuzz · 2012-07-01 21:10 · Score: 3, Insightful

When NTP knows that a leap second is to be added, it (on Linux at least) sets a flag in the kernel to say that at 23:59:59, please continue to 23:59:60 before going to 00:00:00. This is set by NTP anytime on the day that the leap second is due to be implemented, hence why a server running NTP on Linux would know that TODAY a leap second is due (cause they should always be posted at the 23:59:59 cross-over)

We took the coward's way out... by ElVee · 2012-07-02 01:34 · Score: 3, Informative

I work at a fairly large international outfit, with data feeds coming and going to the far ends of the Earth. Everything we do is time-sensitive. Processing messages that depend on prior messages already being processed means we can't gracefully handle things coming in out of order.

We spent lots of time and money studying this problem, hired a high-priced consulting outfit to advise us and spun up lots of projects to mitigate the "risk" of the leap second. There were far too many meetings and conference calls with vendors, VARS and other people that wanted us to pay them for their time. What was determined was that we couldn't guarantee that nothing would crash or (gasp!) messages might be discarded or processed incorrectly, which was a risk we weren't willing to take. We run a full gamut of OSes, from HP/UX, Solaris, Linux, z/TPF, z/OS, DB2 etc etc.. You get the idea. Too many variables and too many systems to update and test with the limited funds and limited timeframe given.

In the end, we avoided the problem by shutting down all (and I do mean ALL) processing and flushing all the transactional systems to disk and suspending EVERYTHING from a minute before until a minute after the leap second. (Was that two minutes or two minutes PLUS one second? Clock math has always eluded me.) Shutting down all these interconnected systems in the correct order was a precision dance that, in the end, we didn't perform very well. Messages did end up being discarded. At precisely :20 seconds after the leap second, we began syncing all our systems with our internal NTP server and then at precisely one minute after, we slowly started everything back up. There were some systems that required a restart. We manually reprocessed those earlier discarded messages just as fast as our little fingers could type. In all it took us about 15 minutes to get everything spun back up, and all that time is getting charged to our SLA, which affects ALL our evaluations and year-end bonuses.

Lots of work was done, overtime was paid and buckets of money were given to lots of high-priced consultants and I personally will take a hit to my paycheck, all over ONE GODDAMNED SECOND.

Let's not do that again, okay?

--
- Pithy comment goes here.

Re: by coolmadsi · 2012-07-02 03:25 · Score: 2

If that actually happened, then they should have just made it do 23:59:59 twice instead of crashing all the computers. I would like somebody to give me a concrete reason why any computer system should actually crash because of a lost second.

If you send 23:59:59 twice, you have the same second in the system twice, which can potentially cause issues with logs. If everything is timestamped to the second/millisecond, how can you be sure an event happened in the first 23:59:59 second, or the second (or subsequent) 23:59:59 second?

Slashdot Mirror

Leap Second Bug Causes Crashes

75 of 230 comments (clear)