Czy zegar Linuksa zawiedzie 19 stycznia 2038 r. 3:14:08?

23

Trochę mnie to martwi. Nazywa się to „problemem roku 2038”. Czy jądro Linuxa lub Ubuntu jest gotowe do obsługi dat po tym dniu, począwszy od 12.04?

time

— ThePiercingPrince
źródło

8

Czy próbowałeś ustawić swój zegar na coś takiego jak 19 stycznia 2038 3:14:07 i poczekaj chwilę?

— gertvdijk

2

Załóżmy, że ten problem istnieje i nie został jeszcze rozwiązany. 12.04 nie będzie wspierane na zawsze, więc ty i wszystkie inne osoby będą na bieżąco aktualizowane, dopóki tak się nie stanie, ponieważ upłynęło wiele lat. Aktualizacja jest łatwa. Jedna z tych aktualizacji z pewnością będzie zawierać poprawkę. Nie ma więc powodów do niepokoju, ale jest to rzeczywiście interesujące pytanie.

— verpfeilt

3

Błąd został już naprawiony.

— ThePiercingPrince

Zegar systemowy nie działa (zresztą i tak na stosunkowo nowym jądrze); niektóre struktury danych (i programy je wykorzystujące) mogą wykazywać anomalne zachowanie. Moim zdaniem będzie to problem z urządzeniami osadzonymi - znacznie rzadziej uruchamiają one bieżący kod.

— Piskvor

1

@hmayag: Nie myślałem „toster”, a bardziej „kontroler sygnalizacji świetlnej”. Te rzeczy są nieco bardziej wytrzymałe niż elektronika klasy konsumenckiej i mogą z łatwością przekroczyć ten okres użytkowania (z częściowymi wymianami, ale prawdopodobnie bez aktualizacji) - IIRC, były pewne problemy z elektroniką z lat 80. tuż po Y2K.

— Piskvor

13

Nie, to nie zawiedzie. W najgorszym przypadku z punktu widzenia programisty będzie działał zgodnie z oczekiwaniami: zostanie zresetowany do daty 1901-12-13 20:45:52:

wprowadź opis zdjęcia tutaj

To w przypadku, gdy nie zaktualizujesz swoich obecnych dystrybucji, dopóki tak się nie stanie. „ Aktualizacja jest łatwa. Jedna z tych aktualizacji na pewno będzie zawierać poprawkę. ” Jak powiedział chocobai .

Pamiętam, że był to ten sam problem / pytanie z 16-bitowymi maszynami przed 2000 rokiem i ostatecznie nie było żadnych problemów.

Rozwiązanie z Wikipedii:

Większość systemów operacyjnych zaprojektowanych do działania na 64-bitowym sprzęcie korzysta już z 64-bitowych time_tliczb całkowitych ze znakiem. Użycie podpisanej wartości 64-bitowej wprowadza nową datę zawijania, która jest ponad dwudziestokrotnie większa niż szacowany wiek wszechświata: od około 292 miliardów lat, o 15:30:08 w niedzielę, 4 grudnia 292 277, 026,596. Możliwość wykonywania obliczeń w terminach jest ograniczona faktemtm_yearużywa podpisanej 32-bitowej wartości int począwszy od 1900 roku. Ogranicza to rok do maksymalnie 2 147 485 547 (2 147 483 647 + 1900). Chociaż rozwiązuje to problem wykonywania programów, nie rozwiązuje problemu przechowywania wartości dat w plikach danych binarnych, z których wiele wykorzystuje sztywne formaty przechowywania. Nie rozwiązuje również problemu dla programów 32-bitowych działających pod warstwami kompatybilności i może nie rozwiązać problemu dla programów, które niepoprawnie przechowują wartości czasu w zmiennych typów innych niż time_t.

Używam Ubuntu 13.04 na 64-bitach i, z ciekawości, ręcznie zmieniłem czas na 2038-01-19 03:13:00. Po 03:14:08 nic się nie stało:

Data i godzina przed 2038-01-19 03:14:08 Data i godzina po 2038-01-19 03:14:08

Więc nie ma się czym przejmować tym problemem.

Więcej na temat:

— Radu Rădeanu
źródło

9

Jeśli resetuje się, kończy się niepowodzeniem, ponieważ przez „fail” mam na myśli „nie działa lub działa niepoprawnie”.

— ThePiercingPrince

1

@LinuxDistance Zdarza się to z twojego punktu widzenia. Ale z punktu widzenia programisty będzie działał zgodnie z oczekiwaniami: zresetuje się . Podobnie było z końcem kalendarza Majów: świat nie zawiódł z tego powodu.

— Radu Rădeanu

10

Nie zgadzam się? z punktu widzenia programisty zegar nie ma resetu, więc to będzie fail

— Nanne

3

Ta dyskusja w komentarzach jest bezcelowa. Pytanie brzmi: „Czy jądro Linuksa lub Ubuntu jest gotowe do obsługi dat po tym?”. Cóż, nie jest w stanie obsłużyć takich dat, więc zawodzi w kontekście tego pytania.

— gertvdijk

2

@gertvdijk „Czy„ bieżące / rzeczywiste ”jądro Linuksa lub Ubuntu jest gotowe do obsługi dat po tym?”

— Radu Rădeanu

7

Możesz sprawdzić, czy czas na komputerze się zawiesi, używając następującego skryptu Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Jeśli twój komputer będzie w porządku, otrzymasz:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Jeśli twój komputer jest podobny do mojego, obejmie go w następujący sposób:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Może to również zrobić:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

— SkylarMT
źródło

Myślę, że testujesz tutaj Perla, a nie prawdziwy system operacyjny w rdzeniu. A może używasz ctime?

— gertvdijk

@gertvdijk Cóż, daje pierwsze wyjście na łatanych komputerach, a mój laptop z Ubuntu daje drugie, podczas gdy trzeci pochodzi z mojego serwera Debian. Właściwie to nie napisałem kodu, cały internet jest w dokładnie takiej samej formie.

— SkylarMT

2

zatwardziały. jeśli masz maszynę 64-bitową, będzie dobrze. Poza tym ... kto z nas będzie miał 32-bitowe maszyny nadal działające w roku 2038?

— jrg

1

Poszukałem tego, by zilustrować problem 2038 współpracownikowi, i 2 lata po opublikowaniu powyższego komentarza nie mam wątpliwości, że w 2038 roku będziemy mieli 32-bitowe maszyny, które zawiodą. Ach, młodzieńczy optymizm.

— jrg

@James, może niektórzy nieświadomie. Prawdopodobnie wtedy będzie osadzony 32-bitowy Linux na urządzeniach IoT, niezałatany. Koniec świata? Nie. Masz problemy w niektórych miejscach? Zdecydowanie.

— Prof. Falken wspiera Monikę

3

Napisałem i opublikowałem krótki artykuł na ten temat w 1996 roku. Obejmował on krótki program C, aby to zademonstrować. Otrzymałem również e-maile od Davida Millsa na temat podobnych problemów z NTP - Network Time Protocol. Na moim 64-bitowym laptopie z Ubuntu 14.04 kod perla nie wykazywał ograniczenia, więc podstawowe biblioteki 64-bitowe musiały zostać zmodyfikowane.

Jednak uruchomienie mojego dawnego kodu testowego pokazuje, że czas wraca do Epoki UNIX. Więc nie wszystko jest dobrze z 32-bitowym kodem z przeszłości.

Mój artykuł z 1996 r. Czas UNIX skończy się w 2038 r.! istnieje na mojej stronie od około 2000 roku. Wariant zatytułowany „Czas UNIX” został opublikowany w 1998 r. w „Najlepszych praktykach w 2000 roku dla Y2K Millennium Computing” ISBN 0136465064.

— oldunixguy
źródło

2

64-bitowy system Linux jest gotowy, przynajmniej jeśli mówisz o podstawowych interfejsach systemu operacyjnego (poszczególne aplikacje mogą go oczywiście popsuć). time_t jest tradycyjnie definiowany jako alias dla „long”, a „long” w 64-bitowym systemie Linux to 64-bit.

Sytuacja w 32-bitowym systemie Linux (i warstwie zgodności dla 32-bitowych plików binarnych w 64-bitowym systemie Linux) jest znacznie mniej różowa. Jest zepsuty i naprawienie go bez zerwania wszystkich istniejących plików binarnych nie jest łatwym zadaniem. Cała gama interfejsów API korzysta z time_t iw wielu przypadkach jest osadzona jako część struktur danych, więc interfejsy API muszą być nie tylko duplikowane, ale także struktury danych, z którymi pracują.

Nawet jeśli istnieje pewien poziom kompatybilności wstecznej, wszystkie pliki binarne, które chcą uzyskać poprawny czas, będą musiały zostać przebudowane, aby móc korzystać z nowych 64-bitowych interfejsów czasowych.

Wykonano już pewne prace (patrz na przykład https://lwn.net/Articles/643234/ i http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ), ale uważamy, że są jeszcze daleko od pełnego rozwiązania. Nie jest jasne, czy kiedykolwiek pojawią się 32-bitowe dystrybucje ogólnego przeznaczenia, które są bezpieczne dla Y2K38.

— Peter Green
źródło