RedHatは警告します。ホームページ:
うるう秒イベントは2016年12月31日23:59:60 UTCで発生します。
感嘆符が前に付いて次のようになります。重要。ユンチョはシステムにどのような害を及ぼしますか？この問題にどのように対処する必要がありますか？
答え1
まったく。
うるう秒は1972年から発生しており、UNIXシステムでもうるう秒が発生しています。傷なしいつも。
RedHat は今回カスタマーサポートの WWW サイトの上部に Amber Alert メッセージを表示することにしました。たとえば、次のようになります。Leap Second バグ 2016年12月31日「うるう秒エラー」について話してください。
ユンチョ間違いではありません、Unixシステムはこれを完全に処理します。何十年もの間、Cライブラリはtm_secドメインが次のことをtm行うことができるというアイデアを奨励してきました。時々値は60です。。
実際に唯一の実際の問題は、UnixとLinuxシステムが好みに応じてさまざまな方法でタスクを処理することです。したがって、どのようなアクションが必要かを知るには、どの設定を選択したかを知る必要があります。
RedHatページは広範な文脈でこれを隠し、TAI-10システムについて誤った仮定をし、UnicesとLinuxオペレーティングシステムに関する一般的な質問に対する答えではありません。RedHat Linuxのみ）。
基本的に何をすべきかを知るには、3つの質問に答える必要があります。
- カーネルクロックはUTCで動作しますか？それともTAI-10で？
- コンピュータの時計を他のシステムと同期させるために何を使用しますか？
- 他のシステムは、うるう秒をどのように処理しますか？
やるべきことのいくつかの例
カーネル時計はTAI-10で、システムはTAI認識ツールを使用してTAI-10サーバーと同期しています。
Daniel J. Bernsteinと同様の同期ツールtaiclock、ローランベルコs6-taiclockまたはOpenBSDのrdate基本的なTAI-10モード。
この場合、うるう秒時計が最新であることを確認する以外は何もする必要はありません。コアクロックは毎秒1SI秒ずつ移動し（オシレータードリフトの変更などを許可）、ホッピングストップウォッチはTAI-10からUTCへの調整を処理します。
最新の状態に保つ必要がある2つのテーブルセットがあります。
- タイムゾーンファイル内のファイルは、
right/システムにタイムゾーンファイルパッケージの最新バージョンがあることを確認することによって最新の状態に保たれます。 - Bernsteinと他の人が使用するツールセットは、次の場所にあります。
/etc/leapsecs.datバーンスタインさんはまだ更新していません
leapsecs.datcr.yp.to、しかし、すでに投稿しました。更新済みleapsecs.datこれには、単一のパッケージに含まれる2016-12-31 23:59:60 UTCうるう秒が含まれますleapsecs。
同期するサーバーもTAI-10を使用しているため、公開する秒も常に1SI秒の長さに設計されています。 TAI-10を使用するサーバーでは、ステッピング、回転、テーリングは発生しません。すべての人は一定の長さのSI秒として選択され、うるう秒はCライブラリの成果物としてのみ表示されます。
カーネル時計はTAI-10で、システムはTAI認識ツールを使用してUTCサーバーと同期されます。
rdate同期ツールはOpenBSDのUTCモードです。
この場合でも、前の場合と同様に、うるう秒時計が最新であることを確認する以外は何もする必要はありません。コアクロックは再び1秒あたり1SI秒で連続的にカチカチとなります。
問題はサーバーがないことです。
- 彼らが塗抹標本うるう秒が過ぎると、彼らは一年の最後の日のほとんどの間に時間が少し遅くなると報告します。時間同期ツールは誤ったUTCと同期を維持するためにTAI-10を不必要に調整し、うるう秒が到達するとTAI-10が1秒遅れます。うるう秒の後、同期ツールはSI秒よりも長いUTC秒に同期すると、欠落している追加のTAI-10クロックサイクルに追いつくためにより速くクロックが必要になり、システムクロック秒は補償のためにSI秒より短くなります。
- 彼らが大虐殺うるう秒が過ぎると、新年の最初の日に少し早い時間が報告されます。時間同期ツールは、この誤ったUTCとの同期を維持するためにTAI-10を不必要に調整します。皮肉なことは、うるう秒でTAI-10ですぐに正確に起動し、翌日は徐々に正しいものから離れて、時間サーバーが徐々にUTCに遅くなり、同期ツールが戻ってくるということです。また、TAI-10の速度を誤ったUTC時間に上げようとしています。
- 彼らがステップうるう秒の場合、単調に増加する時間はまったく報告されませんが、同期ツールによって実行されるうるう秒の挿入は実際に正しく計算されるべきです。ただし、うるう秒の瞬間にサーバーのUTCレポートは次のとおりです。あいまいな。ただし、少なくとも1秒あたり1SI秒の目盛りを表示し、TAI-10は前後数日間正確で、TAI-10をUTC時間と同期させるための不必要な試みはありません。 。
したがって、TAI-10を実行している場合は、UTCタイムサーバーを好む傾向があります。ステップ他のオプションを使用すると、実際にTAI-10時間が加速または遅いUTCと不必要に同期し、1秒あたり1SI秒の特性が失われるため、うるう秒が発生します。
カーネル時計はUTCで、コンピュータはUTCツールを使用してUTCサーバーと同期しています。
この状況は、同期したいタイムサーバーの機能によって分類されます。
- 彼らが塗抹標本うるう秒が過ぎると、彼らは一年の最後の日のほとんどの間に時間が少し遅くなると報告します。時間同期ツールがそのツールと同期し、時計が時間より1日遅くなります。
- 彼らが大虐殺うるう秒が過ぎると、新年の最初の日に少し早い時間が報告されます。時間同期ツールが同期され、時計が一日のうちの一部で前進します。
- 彼らがステップうるう秒を使用すると、単調に増加する時間はまったく報告されず、同期ツールの場合、システムクロックが突然1秒ずつ遅くなるため、修正する必要があります。反応方式は、同期ツールの構成方法によって異なります。
- 彼らは単にステップシステム時計も同様です。この場合、アプリケーションは時間が1秒前に戻るのを見ます。
- 彼らは可能性が高い大虐殺しかし、システムクロックは実際のSI秒よりも長い時間動作し、1日よりはるかに高速です。
- 彼らが発表するうるう秒はステップが近づいているという警告であり、同期ツールに何をすべきかについての決定を伝えます。
- 彼らは単にステップシステム時計も同様です。この場合、アプリケーションは時間が1秒前に戻るのを見ます。
- 彼らは可能性が高い大虐殺または塗抹標本ただし、この場合、システムクロックはその日付の前後の実際のSI秒より数秒長く動作します。
結果
あなたのコンピュータの時間は、UTCサーバー+ UTCコンピュータの場合にのみ正確です。この場合、アプリケーションは時間が逆になるのを見ることになりますが、これはUnixアプリケーションが見たくないことです。他のすべてのUTCサーバー+ UTCシステムの場合、システム時間は最大1日間正確ではありません。
TAI-10-servers+TAI-10-machineの場合、システム時間は常に正確です。 UTCサーバーの1つ+ TAI-10マシンの場合、サーバーはスピードあいまいな UTC 時間にポーリングしない限り、コンピュータの時間も常に正確です。
誤ったシステム時間による結果はアプリケーションレベルで発生します。オペレーティングシステムはこれに満足しています。 （一般的な信念とは異なり、POSIXは実際にシステムの時計が誤って誤っていることを許可します。）できません。そのときに思い浮かぶアイデア、顧客や他のアイデアが2日かかるかもしれません。お客様とお客様は同じ設定を選択していない可能性があります。
混在したタイムサーバーセットと同期することを選択すると、問題が発生する可能性があります。その一部は大虐殺UTC（一部）ステップUTC（一部）塗抹標本UTC。この場合、同期ツールを台無しにすると、面白いことがたくさん起こります。皮肉な部分も多いです。 「愚かな」同期ツールは、どのタイムソースが正確な時間を知らせるかを調べようとする「スマート」同期ツールよりも、同期されていないタイムソースをよりよく処理します。この特別なケースではステッパーだけが正しい時間を知ることができます。しかし、殺人犯と非防犯は何が何であるかについて矛盾する考えを持っています。間違ったUTC時間は次のとおりです。
最後で不名誉な言及は、RedHatページで説明されているLinuxカーネルです。同期ツールは、時間自体を段階的に選択するか、カーネルにそのように指示することができます。 RedHatが報告したように、カーネルの内部タイミングメカニズムが正しく動作しないことからシステム停止に至るまで、これに関連する問題は長い間存在してきました。