Linuxの時計は、2038年1月19日3:14:08に失敗しますか？

23

これについて少し心配です。「2038年問題」と呼ばれます。LinuxカーネルまたはUbuntuは、12.04の時点で、これ以降の日付を処理する準備ができていますか？

time

8

時計を2038年1月19日3:14:07のように設定して、1秒待ちましたか？

— gertvdijk

2

この問題が存在し、まだ修正されていないと仮定しましょう。12.04は永久にサポートされないため、あなたと他のすべての人々は、これが起こるまで更新されたディストリビューションになります。更新は簡単です。これらのアップデートの1つには、必ず修正が含まれます。心配する理由はありませんが、これは確かに興味深い質問です。

— verpfeilt

3

バグはすでに修正されています。

— ThePiercingPrince

システムクロックは（とにかく比較的最近のカーネルではありません）; 一部のデータ構造（およびそれを使用するプログラム）は、異常な動作を示す場合があります。私の意見では、これは組み込みデバイスの問題になるでしょう-それらは現在のコードを実行する可能性がはるかに低いです。

— ピスクヴォー

1

@hmayag：私は「トースター」を考えていませんでした。「トラフィックライトコントローラー」のようです。それらは消費者グレードの電子機器よりも少し頑丈で、その寿命を簡単に超える可能性があります（部品の交換は可能ですが、アップグレードは必要ありません）。

— ピスクヴォー

13

いいえ、失敗しません。最悪の場合、プログラマの観点からは期待どおりに動作します。日付は1901-12-13 20:45:52にリセットされます。

ここに画像の説明を入力してください

これが発生するまで、現在のディストリビューションを更新しない場合に備えて。「更新は簡単です。これらの更新の1つには確実に修正が含まれます。」とchocobai氏は言いました。

2000年以前の16ビットマシンでも同じ問題/質問であり、最終的には問題ではなかったことを覚えています。

ウィキペディアのソリューション：

64ビットハードウェアで実行するように設計されたほとんどのオペレーティングシステムは、既に符号付き64ビットtime_t整数を使用しています。署名された64ビット値を使用すると、宇宙の推定年齢の20倍以上の新しいラップアラウンド日が導入されます。これは、現在から約292億年、292,277,026,596年12月4日日曜日15:30:08です。日付の計算を行う機能は、次の事実により制限されます。tm_year年に1900から始まる符号付き32ビット整数値を使用します。これにより、年は最大2,147,485,547（2,147,483,647 + 1900）に制限されます。これはプログラムの実行に関する問題を解決しますが、バイナリデータファイル内に日付値を保存する問題は解決しません。バイナリデータファイルの多くは厳格なストレージ形式を採用しています。また、互換性レイヤーで実行されている32ビットプログラムの問題は解決しませんtime_t。また、。

64ビットでUbuntu 13.04を使用し、好奇心により、手動で時間を2038-01-19 03:13:00に変更しました。03:14:08以降、何も起こりませんでした。

2038-01-19 03:14:08より前の日時 2038-01-19 03:14:08以降の日時

したがって、この問題を心配する必要はありません。

詳細：

— ラドゥ・ラデアヌ
ソース

9

リセットすると、「失敗」とは「動作しない、または正しく動作しない」ことを意味するため、失敗します。

— ThePiercingPrince

1

@LinuxDistanceこれはあなたの観点から起こります。ただし、プログラマーの観点からは、期待どおりに動作します。リセットされます。それはマヤ暦の終わりと同じでした：このために世界は失敗しませんでした。

— ラドゥラデアヌ

10

同意しません？それはので、プログラマの観点からのクロックは、リセットに想定されていないだろう失敗

— Nanne

3

コメントでのこの議論は無意味です。問題は、「LinuxカーネルまたはUbuntuはこの後の日付を処理する準備ができていますか？」です。まあ、それはそのような日付を扱うことができないので、この質問の文脈では失敗します。

— gertvdijk

2

@gertvdijk「現在の/実際の」「LinuxカーネルまたはUbuntuはこの後の日付を処理する準備ができていますか？」

— ラドゥラデアヌ

7

次のPerlスクリプトを使用して、コンピューターの時間がクラッシュするかどうかを確認できます。

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

お使いのコンピューターに問題がなければ、次のようになります：

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

コンピューターが私のようなものである場合、次のようにラップアラウンドされます。

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

また、これを行うことができます：

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
ソース

コアの実際のオペレーティングシステムではなく、ここでPerlをテストしていると思います。それとも、を使用してctimeですか？

— gertvdijk

@gertvdijkまあ、それはパッチを適用したコンピューターで最初の出力を提供し、私のUbuntuラップトップは2番目を出力し、3番目はDebianサーバーからのものです。実際にコードを書いたのではなく、インターネット上でまったく同じ形式でコードを書いています。

— SkylarMT

2

確認されました。64ビットマシンを使用している場合は、これで問題ありません。それに... 2038年に32ビットのみのマシンがまだ稼働している人はいますか？

— jrg

1

2038年の問題を同僚に説明するためにこれを探しましたが、上記のコメントを行ってから2年後、2038年に32ビットマシンが故障することはほとんど疑いがありません。ああ、若々しい楽観。

— jrg

@ジェームズ、無意識のうちにいくつか。IoTデバイスには、おそらくパッチが適用されていない32ビットLinuxが埋め込まれるでしょう。世界の終わり？いいえ。場所によっては問題がありますか？間違いなく。

— ファルケン教授はモニカをサポートしています

3

1996年に、これに関する短い論文を書いて公開しました。これには、それを実証する短いCプログラムが含まれていました。また、NTP（Network Time Protocol）に関する同様の問題について、David Millsにメールを送りました。Ubuntu 14.04 64ビットラップトップでは、perlコードに制限がなかったため、基礎となる64ビットライブラリを変更する必要がありました。

しかし、私の昔のテストコードを実行すると、時間はUNIXエポックに戻ります。そのため、過去の32ビットコードですべてがうまくいくとは限りません。

私の1996年の論文、UNIXの時間は2038年に終わります！この「UNIX Time」というタイトルの変形版は、1998年に「Y2K Millennium Computingの2000年ベストプラクティス」ISBN 0136465064で公開されました。

— Oldunixguy
ソース

2

少なくとも、コアOSインターフェースについて話している場合は、64ビットLinuxの準備ができています（もちろん、個々のアプリケーションはそれを台無しにする可能性があります）。time_tは伝統的に「long」のエイリアスとして定義され、64ビットのLinuxでは「long」は64ビットです。

32ビットLinux（および64ビットLinuxの32ビットバイナリの互換性レイヤー）の状況はそれほどバラ色ではありません。壊れており、既存のすべてのバイナリを壊さずに修正するのは簡単なことではありません。API全体はtime_tを使用し、多くの場合、データ構造の一部として埋め込まれているため、APIを複製するだけでなく、使用するデータ構造も複製する必要があります。

ある程度の下位互換性がある場合でも、正しい時刻を取得したいすべてのバイナリを再構築して、新しい64ビットタイムインターフェイスを使用する必要があります。

いくつかの作業が行われました（たとえばhttps://lwn.net/Articles/643234/およびhttp://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.htmlを参照）が、完全なソリューションからはまだ長い道のりです。Y2K38で安全な汎用32ビットディストリビューションが存在するかどうかは明らかではありません。

— ピーター・グリーン
ソース