(Was Google translate, now from the comment of imaginator below, thanks)
Better translation of their message to English speaking customers:
During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt.
The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers.
According to heise.de, various Linux distributions are affected by this. Further information can be found at: http://www.h-online.com/open/news/item/Leap-second-Linux-can...
In order to reduce CPU load to a normal level again, a restart of the whole system is necessary in many cases. First, a soft reboot via the command line should be attempted. Failing that, you have the option of performing a hardware reset via the Robot administration interface. For this, select menu item "Server" and the "Reset" tab for the respective server in the administration interface.
Please do not hesitate to contact us, should you have any queries.
Kind regards,
Hetzner Online AG
Stuttgarter Str. 1
91710 Gunzenhausen / Germany
info@hetzner.de
http://www.hetzner.com
During the night of 30.06.2012 to 01.07.2012 our internal
monitoring systems registered an increase in the level of
IT power usage by approximately one megawatt.
The reason for this huge surge is the additional switched
leap second which can lead to permanent CPU load on Linux
servers.
Better translation of their message to English speaking customers:
During the night of 30.06.2012 to 01.07.2012 our internal
monitoring systems registered an increase in the level of
IT power usage by approximately one megawatt.
The reason for this huge surge is the additional switched
leap second which can lead to permanent CPU load on Linux
servers.
In order to reduce CPU load to a normal level again, a
restart of the whole system is necessary in many cases.
First, a soft reboot via the command line should be
attempted. Failing that, you have the option of performing
a hardware reset via the Robot administration interface.
For this, select menu item "Server" and the "Reset" tab
for the respective server in the administration interface.
Please do not hesitate to contact us, should you have any
queries.
Kind regards,
Hetzner Online AG
Stuttgarter Str. 1
91710 Gunzenhausen / Germany
info@hetzner.de
http://www.hetzner.com
I really can't imagine why that would ever happen. What car would ever use a clock for anything essential, instead of a timer? Maybe I'm overestimating the intelligence of car developers, but it seems like the obvious, simple solution.
Engine won't start, service due 300 years ago. I'd be willing to bet $10 there's at least a few floating around with real time clocks, no idea what they'd be used for though. If nothing else there's always in-car navigation and entertainment which are definitely candidates, although I suppose less likely to result in a brick.
I'm engaging in what is commonly known as using one's imagination to make educated guesses at the possible electronic devices within an average motor vehicle (you know, that thing with wheels on it) where a real time clock susceptible to wraparound or overflow might be found, thus resulting in potential malfunction, or in plainer words, "the car won't start, the tuner won't play music, the GPS won't get a signal, this thing is about as useful as a brick".
What car would ever use a clock for anything essential, instead of a timer?
You could say the same thing about the futex option that caused this issue in Linux in the first place. If the futex call specified a timeout in duration rather than an absolute time, this bug wouldn't have been hit (I observed the two different kinds of futex use during the leap second event).
Interestingly, because of significant changes in the way we manufacture cars, I'd imagine there will be far fewer classic cars around in 26 years.
A car today uses a few very large stamped steel components coupled with intricate plastic pieces. Maintaining a car for significant periods of time is far more of an issue than it was with much simpler cars of the past. When a small component in a modern car fails, you need to replace significantly more of the car with a significantly harder to manufacture piece to get it working again.
Perhaps 3D printing will provide us with a way to produce bespoke complicated pieces, but there's a long way for that technology to go before it's usable for steel car components.
Essentially, modern cars are considerably more reliable in the short term, but very, very hard to maintain in the long term. Classic cars in 26 years will primarily be very high end or unusual cars today (I can imagine kit cars, Rolls Royces, Ariel Atoms and other largely custom cars sticking around) and cars that we consider classics today. A car that's made it 30, 40 or 50 years today is likely to make it another 50.
I'd guess it happens by the concurrence of a lep second and a leap second implementation bug. The bug without leap seconds would also not lead to problems.
Better translation of their message to English speaking customers:
During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt.
The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers.
According to heise.de, various Linux distributions are affected by this. Further information can be found at: http://www.h-online.com/open/news/item/Leap-second-Linux-can...
In order to reduce CPU load to a normal level again, a restart of the whole system is necessary in many cases. First, a soft reboot via the command line should be attempted. Failing that, you have the option of performing a hardware reset via the Robot administration interface. For this, select menu item "Server" and the "Reset" tab for the respective server in the administration interface. Please do not hesitate to contact us, should you have any queries.
Kind regards,
Hetzner Online AG Stuttgarter Str. 1 91710 Gunzenhausen / Germany info@hetzner.de http://www.hetzner.com