Heute morgen um 2.00 Uhr haben uns einige Server ordentlich Probleme bereitet. Prozesse wie ksoftirqd haben überdurchschnittlich viel CPU konsumiert und die Load ging raketenhaft nach oben. Ein kurzer Blick auf den Graphen und der Vergleich mit anderen Systemen lässt den Zeitpunkt auch schnell lokalisieren.
Was genau dann aber um 2.00 Uhr passiert ist, war dann im Logfile zu sehen.
Jul 1 01:59:59 icinga-web kernel: [725419.171543] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:11:33 icinga-web ntpd[2027]: kernel time sync status change 0001
Ursache war eine sogenannte Schaltsekunde, welche nachfolgend (ich zitiere Wikipedia) erläutert wird.
Eine Schaltsekunde ist eine bei Bedarf in die Koordinierte Weltzeit UTC zusätzlich eingefügte Sekunde, um sie mit der Universellen Sonnenzeit UT1 zu synchronisieren (dUT1 < 0,9 s). Sie wird vom Internationalen Dienst für Erdrotation und Referenzsysteme (IERS) festgelegt und eingeführt.
Was genau passiert wird noch auf einen Buglisten und im IRC diskutiert aber grundsätzlich sind wohl entsprechende Linux-Locks (Futex) und deren Timeout durch die Umstellung für die Konsumierung der CPU verantwortlich. Mit folgenden Commands lässt sich das Problem lösen und die Load nähert sich umgehend wieder an normale Werte an.
/etc/init.d/ntp stop; export LANG="en_EN"; date -s "`date`"; touch /tmp/leap_second ; /etc/init.d/ntp start
Hier noch ein paar Links zu Thema welches heute morgen nicht nur uns, sondern auch Amazon AWS, den Flughafen Sydney und viele große ISPs betroffen hat:
- Hohe Auslastung MySQL
- MySQL and the Leap Second
- Leap Second in Red Hat
- Fatale Sekunde
- Linux Kernel List
- Chaos am Flughafen von Sydney
Vielen Dank an unsere Managed Service Truppe, speziell Marcus und Sebastian für die tolle Arbeit. Noch allen einen schönen Sonntag.
Danke … hat mir eine Runde Google erspart. 😀
So macht der Post dann auch Sinn und die Mühen der Anderen haben sich gelohnt.
Hi,
vielen Dank für den Post. Das hat mir den Tag gerettet.
Wir hatten das Problem auf SLES Systemen.
Gruß
Christian
Was für SLES System waren das?
Denn laut dem Novell Support seien die SLES System davon nicht betroffen:
ui, grade ne mail von hetzner deswegen bekommen. danke für den tip. sofort ausgeführt und klappt scheinbar auch soweit 🙂
tausend dank!
Auf meinem Debian Squeeze System lässt sich mit
date -s „`date`“
das Datum nicht neu setzen, da date ein deutsches Datumsformat ausgibt auch wenn ich die LANG Variable setze.
Folgender abgewandelter Befehl hat bei mir problemlos geklappt.
/etc/init.d/ntp stop; date -s „`date -R`“; touch /tmp/leap_second ; /etc/init.d/ntp start
Hier gibts noch ein paar Hintergrundinfos von Heise:
http://www.heise.de/newsticker/meldung/Schaltsekunden-Bug-in-Linux-verschwendet-Strom-1631325.html