システムが2038年以降の日付を設定すると、ntpdateは失敗します。

システムが2038年以降の日付を設定すると、ntpdateは失敗します。

現在の正確な日付は2016年5月25日金曜日12:11:07 CSTです。

日付を「2018/01/01」に変更すると、ntpdateが正常に動作します。

日付を「に変更すると2099/01/01"、ntpdateが正しく動作しません。

いいね:

[root@oldboylinux ~]# date -s "2018/01/01"
Mon Jan  1 00:00:00 CST 2018

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
25 Mar 12:06:22 ntpdate[7187]: step time server 216.229.0.179 offset -55857225.378947 sec

悪い:

[root@oldboylinux ~]#date -s "2099/01/01"
Thu Jan  1 00:00:00 CST 2099

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
 1 May 18:36:59 ntpdate[7189]: step time server 216.229.0.179 offset 1682966210.024232 sec

5月1日月曜日18:41:18 CST 2152が無効な日付です。

ntpdate有効な範囲はありますか?

答え1

まず、いくつかの注意:

  • NTPの現在のバージョン(v4)時代を使って働きます。

  • エポックは136年(符号なしの32ビット整数で表される秒数)です。それとも

      60 * 60 * 24 * 365 * 136 = 4288896000 
                          2^32 = 4294967296
    
      4294967296 − 4288896000 = 6071296
       6071296 / 60 / 60 ∕ 24 ≈ 70 (days, not accounting for leaps)
    
  • 0時代:これ黄金時代または基準日「0時代」、これは1900年1月1日00:00 UTC時間です。

  • 時代1:2036年初めから始まります。 (UNIX-2038 2年前)

  • 時代2:物語は2172年初めに始まります。

  • など。 (他の例については、以下を確認してください。RFC 5905 14ページ.)

  • ntpdate64ビットNTPタイムスタンプを使用します。秒は32ビット、分数は32ビットです。

  • おそらく少し混乱する可能性があります。 NTP-dateは128ビットを使用し、時代を含みます。これは、宇宙の年齢にわたって遠い未来まで広がります。

で述べたようにNTP部分の"2038年の問題" - ウィキペディアページ君は絶対的な限界がある68歳2つのNTPタイムスタンプの間。 (136 / 2 = 68)。ただし、あいまいさを排除するには、より狭い周波数帯域を使用する必要があります。

NTPタイムスタンプは、絶対時間ではなく相対時間に基づいて機能します。サーバーは、独自の時間の相対オフセットを介してクライアントに修正を提供します。つまり、次のようには言いません。

—2016年3月26日付

代わりに(NTPが動作するように単純化されている):

- あなたは+123412512.918秒遅れています、または:
— あなたは-2652221.3466秒遅れています、等。

またはRFCから引用してください。

タイムスタンプは符号なし値であり、これに対するアクションは同じまたは隣接するエポックの結果を生成します。 Epoch 0には、2036年の特定の時点までの日付が含まれています。メインタイムからタイムスタンプフィールドが循環され、Epoch 1のデフォルト日付を設定します。

あなたの年が2099年の場合、あなたはすでに68年以上、つまり約15年後です。あなたは2152年に終わり、私たちが得るものは次のとおりです。

 2152 - 2016 = 136 (One era)

または別の言葉で表現すると:

                    2099 - 2036 = 63          (years into era 1)
        63 * 365 * 24 * 60 * 60 = 1986768000  (approx NTP time stamp for 2099)
       116 * 365 * 24 * 60 * 60 = 3658176000  (approx NTP time stamp for 2016)
       3658176000 - 1986768000  = 1671408000  (approx diff)
1671408000 / 60 / 60 / 24 / 365 = 53          (approx years)

1986768000 < 3658176000 thus add 1671408000

2099 + 53 = 2152 (the year your system was corrected to)

はい、あなたの質問に答えると、次のようになります。

——ntpdate有効範囲がありますか?

はい。 ±68歳、でも最大有効範囲少し狭いです。

NTP自体は無制限です。

見るRFC 5905興味があれば。さらに、古い RFC には興味深い情報を含めることができます。付録 E. NTP 時間スケールとタイミング方法 RFC 1305から


(取り付け: UNIXタイムスタンプと比較すると1970 + 68 = 2038.)

答え2

あなたが見ているのは、2038年の問題、つまりY2K38バグという一般的な「バグ」で、32ビットLinuxサーバーにまだ存在します。

2000年ごろに、私たちは2000年/千年のエラーに加えて、将来別の時間関連のエラーがあることに気づきました。 (はい、私はY2K「予防」チームの一員でした)

Unix epochは1970年1月1日に開始された32ビット秒カウンタで、符号付き32ビット整数であるため、標準規格では03:14:07に制限されています(一部のシステムではまだ利用可能です)。時は2038年1月19日。https://en.wikipedia.org/wiki/Year_2038_problem

最新の実装では64ビットに拡張されました。

NetBSDバージョン6.0(2012年10月リリース)以降、NetBSDオペレーティングシステムは32ビットアーキテクチャと64ビットアーキテクチャの両方に64ビットtime_tを使用します。 32ビットのtime_tを使用する古いNetBSDバージョン用にコンパイルされたアプリケーションはバイナリ互換性層を介してサポートされていますが、これらの以前のアプリケーションは依然として2038年の問題の影響を受けます。 [13]

2014年5月にリリースされたバージョン5.5以降、OpenBSDも32ビットおよび64ビットアーキテクチャに64ビットtime_tを使用します。 NetBSDと比較すると、バイナリ互換性層はありません。その結果、32ビットのtime_tを期待するアプリケーションとtime_tとは異なるものを使用して時間値を格納するアプリケーションがクラッシュする可能性があります。 [14]

Linuxは、以前のバージョンとの互換性のため、64ビットアーキテクチャでは64ビットtime_tのみを使用し、純粋な32ビットABIは変更されません。 [15]現在進行中の作業は、32ビットアーキテクチャで64ビットtime_tをサポートする組み込みLinuxシステムに焦点を当てています。

民俗史の一部であり、やや洗練された詐欺であるJohn Titorは、2038年に将来の遺産を正すのに役立つメインフレームを獲得するために時間を過ごしました。 /核戦争が起こると予測しました。私たちの平行現実。

http://www.strangerdimensions.com/2011/10/03/john-titor-the-ibm-5100/

ジョンティトの物語は2036年に始まります。 Titorは、時間旅行を開始するために選択された7人のチームのメンバーです。彼は利己的で冷笑的で腐敗した政府によって破壊され、核戦争によって荒廃した世界で想像できない恐怖を経験しています。説得力のある技術は、2038年に発生する可能性があるUNIXタイムアウトエラーのために脅威を受けています。

また参照してくださいhttps://en.wikipedia.org/wiki/9223372036854775807

32ビットタイプを使用するシステムは2038年の問題に対して脆弱であるため、多くの実装がより広い64ビットタイプに移行しており、最大値は今から2920億年に相当する263−1です。

それから私はntpdateの質問に戻ります。

2038年の限界について。したがって、問題はtime_tが32ビット符号付き整数であることです。つまり、32ビット整数で、最後のビットは信号専用です。したがって、実際には数字(-0x7fffffffと+7ffffffff(+2147483647)の間の秒数のみを保存できます。したがって、+2147483647は1970年1月1日に間隔表示を+2147483647秒に制限します。意味します 2038 年 1 月 19 日 03:14:07 UTC に基づいてシステムに日付を保存します。

2038年以降の日付に関する問題は、文字列を内部表現(time_t / 32ビット整数)に変換するコードルーチンがライブラリの実装に応じて改行されるか、単に1 / 0秒にリセットされることです。

あなたの帽子の年について。システムのtime_tは符号付き整数であるため、ライブラリは符号なし整数値で上限を確認します。これにより、1970年1月1日以降、+4294967295秒に2106年頃の上限が提供されます。実装に応じて、チェックは実際には文字列でさらに実行できます。または、32ビット整数の属性が原因で動作が発生し、ntpdateコードのみがチェックされます。

INT_MAX(32 ビット) = 2147483647
UINT_MAX(32 ビット) = 4294967295(0xffffffff)

~からhttps://en.wikipedia.org/wiki/Year_2038_problem

たとえば、time_tを符号なし32ビット整数に変更すると、範囲は2106年まで拡張され、1970年以前の日付を保存、検索、または操作するプログラムに悪影響を及ぼします。これらの日付は負の数で表示されるためです。

最後の脚注として、システム/OSコードとRTCクロックでy2k38コンプライアンスが不足する可能性があることに注意してください。

OSレベルでは、64ビットLinux(アーキテクチャが許可している場合)を使用すると問題を解決できます。32ビットLinuxを使用すると近いうちに問題が解決します。

以前のシステムのRTCの場合、これはntpdが開始され、システムの日付を変更するまで、少なくともログから2038年以降に歪んだデータを受け取ることを意味します。

関連情報