Re: Schaltsekundenbug?
Hallo,
>kann mir jemand mal bitte den Ablauf dieses Schaltsekundenbugs erklären?
>
>Bis hierhin ist mein Verständnis da:
>- Linux-Host mit betroffenem Kernel läuft mit ntp-Zeitsynchronisierung
>- es wird 01.07.2012 00:00 UTC (02:00 MESZ)
Nicht ganz. Der NTP Server kündigt dem NTP Client rechtzeitig an, dass
es die Schaltsekunde geben wird. Um 30.06.2012 23:59:60 UTC (ja, diese
Sekunde gibt es!) wird im Kernel das Schaltsekunden-Flag gesetzt. Das
hat zur Folge, dass beim Sprung auf auf den 01.07.2012 00:00:00 UTC
die Systemzeit (Anzahl der Sekunden seit 1.1.1970 0:00:00) _nicht_ um
eine Sekunde hochgezählt wird. Stattdessen wird im Kernel Log die
Meldung "Clock: inserting leap second 23:59:60 UTC" geloggt.
>- der/die ntp-Server sind ab diesem Zeitpunkt eine Sekunde zurück
>gegenüber der Systemzeit auf dem Linux-Host
>
>Eigentlich müsste der ntp-Client auf dem Linux-Host dann klaglos die 1
>Sekunde Differenz ausgleichen!?
Da braucht nichts mehr ausgeglichen zu werden, da der Kernel das bereits
weiss.
>Wo ist der Bug?
Zunächst wurde vermutet, dass es ein Locking-Problem im Zusammenhang
mit dem Loggen der o.g. Meldung war.
http://www.heise.de/newsticker/meldung/Schaltsekunde-Linux-kann-einfrieren-1629683.html
Diesen Bug gab es im Kernel zwar auch mal, er wurde aber schon vor
längerer Zeit behoben. Außerdem hätte der Kernel bei diesem Bug
abstürzen müssen; eine plausible Erklärung für das auf zahlreichen
Servern beobachtete Lastverhalten ist dies nicht.
Eine plausiblere Analyse wurde erst gestern veröffentlicht.
http://www.heise.de/newsticker/meldung/Schaltsekunden-Bug-in-Linux-verschwendet-Strom-1631325.html
Danach gibt es wegen der Schaltsekunde eine Diskrepanz einer Sekunde
zwischen der Zeit des High Resoltion Timers (Hrtimer) und der
(korrigierten) Systemzeit. Wenn ein Programm den Hrtimer daraufhin
für eine Wartezeit von unter einer Sekunde nutzt, kehrt der Syscall
sofort zurück, anstatt die geforderte Anzahl von Millisekunden zu warten.
Viele Thread-Bibliotheken nutzen den Hrtimer für das Warten auf Locks.
Daher isst der Fehler vor allem bei Anwendungen aufgetreten, die viel
mit Threads arbeiten, z.B. Java-Serverdiensten und MySQL.
Gruß, Harald
Reply to: