Problem roku 2038: kiedy zegar Uniksa się przekręci

Zegar, który zaczął tykać 1 stycznia 1970

Na początku lat 70. twórcy systemu UNIX w Bell Labs musieli rozstrzygnąć pozornie banalną kwestię: jak komputer ma przechowywać datę i godzinę. Wybrali rozwiązanie proste i eleganckie. Czas zapisywany jest jako liczba sekund, które upłynęły od 1 stycznia 1970 roku, godz. 00:00:00 UTC. Ten moment nazwano epoką Uniksa (ang. Unix epoch), a sam licznik czasem uniksowym (Unix time).

Taki zapis ma wiele zalet. Żeby policzyć, ile czasu minęło między dwoma zdarzeniami, wystarczy odjąć od siebie dwie liczby. Nie trzeba się przejmować miesiącami o różnej długości, latami przestępnymi ani strefami czasowymi. Nic dziwnego, że ten pomysł przejęły kolejne systemy, a razem z językiem C, który współtworzył Dennis Ritchie, ojciec C i UNIX-a, rozszedł się po całym świecie IT. Dziś czas uniksowy wykorzystują Linux, macOS, Android, iOS, bazy danych, języki programowania, routery, a nawet pralki.

Jest jednak haczyk. Licznik zapisywano w zmiennej typu time_t, która przez dziesięciolecia miała zwykle 32 bity i była liczbą ze znakiem. Na początku lat 70. wydawało się, że to mnóstwo miejsca.

Matematyka katastrofy: 2 147 483 647 sekund

32-bitowa liczba ze znakiem może przyjąć największą wartość 2 147 483 647. Gdy dodamy tyle sekund do 1 stycznia 1970, otrzymamy dokładnie wtorek, 19 stycznia 2038 roku, godz. 03:14:07 UTC. W Polsce będzie wtedy 04:14:07.

Co się stanie sekundę później? Licznik nie przejdzie na kolejną wartość, tylko się przepełni (integer overflow). Ponieważ najstarszy bit oznacza znak, liczba przeskoczy na największą wartość ujemną, czyli -2 147 483 648. System, który nie wie, że coś poszło nie tak, odczyta ją jako 13 grudnia 1901 roku, godz. 20:45:52.

Skutki mogą być bardzo różne:

• certyfikaty i licencje nagle uznane za nieważne albo jeszcze niewydane,
• zadania harmonogramu (cron, kopie zapasowe) uruchamiane w złym momencie albo wcale,
• błędne sortowanie logów i transakcji,
• pętle oczekiwania, które nigdy się nie kończą, bo czas zaczął płynąć wstecz,
• awarie aplikacji, które nie przewidziały ujemnego znacznika czasu.

Problem bywa nazywany Y2K38 albo, z przymrużeniem oka, Epochalypse, czyli połączeniem słów epoch i apocalypse.

Pierwsze ofiary pojawiły się dużo wcześniej

Wiele osób sądzi, że problem roku 2038 da o sobie znać dopiero w 2038 roku. Tymczasem zaczął gryźć już dawno, bo oprogramowanie często liczy daty przyszłe: terminy ważności, okresy kredytów czy limity czasu.

Najsłynniejszy przypadek wydarzył się w maju 2006 roku. Serwer WWW AOLserver miał w konfiguracji domyślny limit czasu zapytania do bazy danych ustawiony na miliard sekund, czyli około 31,7 roku. Programiści uznali, że to w praktyce nieskończoność. Gdy jednak do bieżącej daty dodano miliard sekund, wynik po raz pierwszy przekroczył 19 stycznia 2038. Licznik się przepełnił, a serwery zaczęły się wysypywać. Oprogramowanie zawiodło więc 32 lata przed oficjalną datą katastrofy.

Podobne kłopoty mają systemy finansowe liczące kredyty hipoteczne na 30 lat i więcej. Umowa podpisana dziś kończy się już po 2038 roku, więc system z 32-bitowym time_t może źle wyliczyć harmonogram spłat.

Kuzyn pluskwy milenijnej, tylko trudniejszy

Problem roku 2038 często porównuje się do pluskwy Y2K i paniki z przełomu tysiącleci. Mechanizm jest podobny, bo w obu przypadkach ograniczony zapis daty kończy się w konkretnym momencie. Są jednak dwie ważne różnice.

Po pierwsze, Y2K dotyczył głównie aplikacji biznesowych pisanych w COBOL-u na komputerach typu mainframe, które dało się zinwentaryzować i poprawić. Y2K38 siedzi znacznie głębiej: w jądrach systemów operacyjnych, bibliotekach systemu, formatach plików i protokołach sieciowych.

Po drugie, w 2038 roku nadal będą działać miliardy urządzeń wbudowanych (embedded): sterowniki przemysłowe, kamery IP, rejestratory, centrale alarmowe, bramy parkingowe czy systemy w samochodach. Wiele z nich ma 32-bitowe procesory, działa latami bez aktualizacji, a ich producenci dawno zniknęli z rynku. Takiego sprzętu nie da się po prostu załatać.

Y2K38 nie jest też jedynym takim licznikiem. Branża IT ma już doświadczenie z kilkoma podobnymi przepełnieniami, co dobrze widać w tabeli poniżej.

Jak świat IT naprawia zegar Uniksa

Rozwiązanie jest koncepcyjnie proste: zamiast 32 bitów trzeba użyć 64-bitowego time_t. Taki licznik wystarczy na około 292 miliardy lat, czyli ponad dwadzieścia razy dłużej, niż istnieje Wszechświat. Wdrożenie tej zmiany zajęło jednak branży kilkanaście lat.

• Systemy 64-bitowe (dziś większość serwerów i komputerów) od dawna używają 64-bitowego time_t, więc samo jądro jest w nich bezpieczne.
• Jądro Linux 5.6 (2020) dodało obsługę 64-bitowego czasu także na platformach 32-bitowych. To efekt wieloletniej pracy społeczności, o której pisaliśmy w historii Linusa Torvaldsa i Linuksa.
• Biblioteka glibc 2.34 (2021) pozwoliła programom 32-bitowym korzystać z 64-bitowego czasu.
• Systemy plików również musiały się zmienić. Ext3 nie zapisze daty po 2038 roku, ext4 z większymi i-węzłami sięga do 2446 roku, a XFS z opcją bigtime aż do 2486 roku.
• Dystrybucje, takie jak Debian i Ubuntu, przebudowały pakiety dla 32-bitowych architektur ARM tak, by używały 64-bitowego czasu.

Ryzyko kryje się dziś głównie w warstwie aplikacji i danych. Przykładem jest typ TIMESTAMP w MySQL, który nadal kończy się na 2038-01-19 03:14:07 UTC. Do tego dochodzą stare skrypty, formaty plików binarnych i oprogramowanie skompilowane dawno temu.

Czy problem roku 2038 dotyczy Twojej firmy?

Do 2038 roku zostało nieco ponad 11 lat. Dla serwera to dwa lub trzy cykle wymiany, ale wiele urządzeń w firmach pracuje dłużej, niż ktokolwiek planował. Warto zadać sobie kilka pytań:

1. Czy w firmie działają stare serwery lub maszyny wirtualne z 32-bitowymi systemami, np. starszym Linuksem albo urządzeniem NAS sprzed dekady?
2. Czy używacie urządzeń wbudowanych (rejestratory CCTV, kontrola dostępu, sterowniki produkcyjne), których producent nie wydaje już aktualizacji?
3. Czy aplikacje biznesowe zapisują w bazie daty przyszłe, np. terminy umów, gwarancji albo ważności licencji?
4. Czy macie dedykowane oprogramowanie napisane wiele lat temu przez firmę, która już nie istnieje?

Na szczęście przygotowania nie wymagają rewolucji. Wystarczy uwzględnić rok 2038 przy planowaniu wymiany sprzętu i inwentaryzacji systemów. Jeśli Twoje serwery pracują bez stałego nadzoru, takie ukryte ryzyka pomoże wychwycić regularne utrzymanie serwerów, obejmujące przegląd wersji systemów, aktualizacje i plan wycofania przestarzałych maszyn. Pluskwa milenijna nauczyła nas, że katastrofy nie było właśnie dlatego, że ludzie zaczęli działać zawczasu.