Kilka dni temu dodatkowa sekunda zwana sekundą przestępną spowodowała wiele problemów na systemach operacyjnych Linux. Dodana została ona w nocy z dnia 30 czerwca 2012 na 1 lipca 2012 roku. Ta jedna sekunda więcej spowodowała na niektórych systemach znaczący wzrost użycia procesora a w najgorszych przypadkach zawieszanie się całego systemu. Czy ten błąd był do przewidzenia? Czy można go było uniknąć? Czy się powtórzy?
Sekunda przestępna
Raz na kilka lat Międzynarodowa Służba Ruchu Obrotowego Ziemi i Systemów Odniesienia (ang. International Earth Rotation and Reference Systems Service, w skr. IERS), ogłasza konieczność zsynchronizowania czasu słonecznego z uniwersalnym czasem koordynowanym (UTC). Dodawana lub odejmowana jest wtedy jedna sekunda. Pierwsza taka synchronizacja miała miejsce 30 czerwca 1972.
Problemy na Linuksie
Dnia 30 czerwca 2012 roku o godzinie 23:59:60, duża część systemów operacyjnych Linux działających pod kontrolą jądra od wersji 2.6.26 oraz jądro 3.3, powodowała zwiększenie użycia procesora lub zawieszenie się. Jak się okazuje problem ten występował wcześniej. Podobną awarię odnotowano 31 grudnia 2008 roku.
W dystrybucji Debian Squeeze problem objawił się brakiem odpowiedzi na pakiety ICMP oraz pustym czarnym ekranem po dodaniu dodatkowej sekundy.
Jak zauważyła Mozilla Foundation, problemy pojawiły się również w serwerze MySQL oraz oprogramowaniu Java.
Źródłem problemu okazało się samo jądro systemu jak wyjaśnia John Stultz (Upstream Kernel Engineer, IBM) w dwóch poprawkach: PATCH 1, PATCH 2. Podsystem NTP, który wykorzystywał funkcję hrtimer, do wprowadzania sekund przestępnych, mógł wprowadzić system operacyjny w Livelock.
Zwiększone zużycie prądu
Ciekawe informacje opublikowało również data center Hetzner Online. W nocy z 30 czerwca na 1 lipca wzrosło zużycie prądu do około 1 megawata. Było to spowodowane 100% zużyciem procesora na wielu serwerach.
Problem został szybko opisany przez firmę, oraz rozesłano mailing do klientów w jaki sposób mogą rozwiązać problem jeżeli zużycie procesora znacząco wzrosło.
Rozwiązanie problemu
Jak zauważyli administratorzy i programiści, rozwiązanie problemu z wysokim obciążeniem procesora jest bardzo proste. Pomaga restart całej maszyny lub ponowne ustawienie daty za pomocą polecenia:
date -s "$(LC_ALL=C date)"
Część administratorów na ten dzień wyłączyło demona NTP oraz uruchomiło specjalny skrypt napisany w Perlu, który resetuje przestępną sekundę.
Inne problemy z datą
To nie jedyne problemy związane z datą jakie wystąpiły w świecie IT. Najsłynniejszym przypadkiem tego typu była tzw. pluskwa milenijna określana problemem roku 2000.
Ciekawym przypadkiem okazał się błąd Y2K1 w projekcie SpamAssasin. Wywołał on niemiłą niespodziankę, kiedy zaczął traktować jako SPAM wszystkie maile z roku 2010.
Kolejny problem jaki nas czeka to rok 2038. Dokładnie to 19 stycznia 2038 o godzinie 3:14:07, systemy Unix oraz Linux mogą przestawić się na datę 13 grudnia 1901, godzina 20:45:52. Dlaczego? Należy pamiętać, że w systemach Uniksowych czas jest liczony jako sekundy, które upłynęły od daty zerowej, czyli 1 stycznia 1970 godz 0:00:00. Czas ten trzymany jest w 32 bitowej zmiennej, która może przyjąć największą wartość 2 147 483 647.
Zatem po upływie kolejnej sekundy powinien nastąpić przeskok do liczny -2 147 483 648, co właśnie wskazuje datę 13 grudnia 1901, godzina 20:45:52.
Zapobiec problemowi można przejść na 64-bitową reprezentację czasu (typ time_t). Jest to tylko obejście problemu, gdyż wystąpi on w roku 9223372034708485227, czyli za około 292 miliardy lat.
Więcej informacji:
Coś gdzieś widziałem opisane po angielsku, ale średnio mnie to interesowało i średnio wiedziałem o co chodzi. Dzięki za ciekawe opisanie i wyjaśnienie problemu :)
Na h-online było, ale tu jest lepiej i ciekawiej opisane. ;)
A jak to rozwiązują inne systemy? No bo skoro czas jest przechowywany w 32 bitowej zmiennej i zmieniamy ta zmienną na 64 bitową to nie jako omijamy problem, ale jak go inaczej składować? Zawsze będzie ograniczenie pojemności. Po zmianie na 64 bitowy typ będziemy mieć sporo czasu, przez ten czas na pewno powstaną 128 bitowe procki i 256 bitowe, a może nowe rozwiązania?
Na Architekturze Komputerów w wykładach mam napisane, że przeszliśmy z układów analogowych na cyfrowe co zwiększyło prędkość o wiele rzędów, jednak układy elektroniczne STABILNIE mogą pracować tylko w dwóch stanach 0 i 1(true/false). Podkreślam słowo "stabilnie", może z czasem stabilnie będą mogły pracować w więcej niż dwóch stanach, np. w trzech, a to nam daje 3^64 pojemności zmiennej.
"Podkreślam słowo "stabilnie", może z czasem stabilnie będą mogły pracować w więcej niż dwóch stanach, np. w trzech, a to nam daje 3^64 pojemności zmiennej. "
Tylko po co . Więcej możliwych stanów tranzystora to więcej możliwych błędów i dużo bardziej skomplikowana konstrukcja. Lepiej pójść w więcej bitów, a i tak nie ma co przesadzać. Dużo bitów to marnowanie z kolei pamięci.
> Jest to tylko obejście problemu, gdyż wystąpi on
> w roku 9223372034708485227, czyli za około
> 292 miliardy lat.
To nie jest obejscie, ale rozwiazanie.
To tak jakby mowic, ze obejsciem problemu nieistnienia nieskonczonej pamieci jest tworzenie skonczonych dyskow. Albo ze 4 cyfry roku nie rozwiazuja problemu Y2K, bo problem powrocie w roku 10000.
Tych problemow nie da sie fizycznie rozwiazac, wiec wszelkie rozsadne pomysly nalezy traktowac jak rozwiazanie. *Obejsciem* kwestii zapisu daty bylo uzycie int32, bo to nie byla rozsadnie duza zmienna.
Obejsciem problemu reprezentacji znakow bylo ASCII – UTF jest rozwiazaniem pomimo, ze przeciez teoretycznie mozna wyobrazic sobie taka ekspansje jezykow i uzywanych znakow, ze dla pojedynczego znaku zapisanego w UTF bedzie potrzeba kilkudziesieciu dyskow twardych.
Zastanawia mnie tylko skad wzial sie problem. Przezylem juz kilka przestepnych sekund na Linuksie i jakos nic sie nie stalo. Rozumiem aplikacje uzywajace czasu do wlasnych celow, dla ktorych nagle minutowy okres miedzy tymi samymi ilosciami sekund w dacie wynosl 61 sekund. Timery 60 sekundowe w aplikacjach nie powinny byc podatne o ile nie zakladaja ze dzialaja na systemie czasu rzeczywistego. Ale co mialoby rozwalic caly system?!
Stało się w 2008.
[…] historię zaczynamy od niesławnej dodatkowej sekundy, zwanej sekundą przestępną, która spowodowała na niektórych systemach znaczący wzrost […]