Seite wählen

Leap Second Problem auf Debian und anderen

von | Jul 1, 2012 | Monitoring & Observability, Linux, Icinga

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:

Vielen Dank an unsere Managed Service Truppe, speziell Marcus und Sebastian für die tolle Arbeit. Noch allen einen schönen Sonntag.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

7 Kommentare

  1. cruiser

    Danke … hat mir eine Runde Google erspart. 😀

    Antworten
  2. Bernd Erk

    So macht der Post dann auch Sinn und die Mühen der Anderen haben sich gelohnt.

    Antworten
  3. Christian

    Hi,
    vielen Dank für den Post. Das hat mir den Tag gerettet.
    Wir hatten das Problem auf SLES Systemen.
    Gruß
    Christian

    Antworten
  4. Andreas Paul (@xorpaul)

    Was für SLES System waren das?
    Denn laut dem Novell Support seien die SLES System davon nicht betroffen:

    Hi,
    vielen Dank für den Post. Das hat mir den Tag gerettet.
    Wir hatten das Problem auf SLES Systemen.
    Gruß
    Christian

    Antworten
  5. hausi

    ui, grade ne mail von hetzner deswegen bekommen. danke für den tip. sofort ausgeführt und klappt scheinbar auch soweit 🙂
    tausend dank!

    Antworten
  6. Marius

    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

    Antworten

Trackbacks/Pingbacks

  1. webtropia.com Blog » Probleme mit der Schaltsekunde auf Debian-basierten Servern - [...] und weitere technische Hintergrund-Informationen zu diesem Software-Probleme finden sich auf dem Netway-Blog. Solltet euer Server auch nach einem Reboot…
  2. Böse Schaltsekunde – Leap Second und Debian: Hohe Last durch mysql › wemaflo.net - [...] bei blog-windfluechter.net, bei Netways gab es die Lösung. Dieser Beitrag wurde unter Linux abgelegt und mit Bug, CPU Load,…

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Monitoring & Observability | Linux | Icinga

Herausforderungen beim Prometheus Scaling

Prometheus ist eine ausgezeichnete Monitoring-Lösung, wenn es um die Überwachung von Verfügbarkeit und Performance geht. Das initiale Deployment geht schnell und mit ein bisschen PromQL KnowHow hat man die Dashboards und Alarme schnell am Laufen. Schon steht die...