NTPおよび時刻同期操作に関連するシステムエラーを調査しています。この質問は再現するのが難しいので、他の条件下で予想される結果が出ていることを確認するためにいくつかの健全性チェックを行いました。
私の質問は、ntpqで使用されているピアステータスレポートと、特定の条件で私が見ているものが合理的かどうかについてです。詳しく説明しますが、ntpqピアレポートがどのように正しいかを理解するのが困難です。
私は通常の動作に興味があるのでUnix / Linuxサイトに問い合わせており、NTPはUnixに由来していると仮定します。ただし、完全性のために、このntpqおよびntpデーモンはWindows Serverで実行されます（重要な場合はMeinbergのサードパーティ製ソフトウェアを使用）。
タスク仮説は、NTPサーバーが何らかの方法で応答しないため、潜在的に障害のあるフェイルオーバー状況（別のソースに切り替える）が発生することです。次のステップは、同様のエラーが発生するように強制できることを確認することです。
（以下の手順では、接続と切断は、そのサーバーでイーサネットケーブルを接続または切断するだけで簡単に行われます。）
1つのNTPサーバーが接続されていて1つのNTPサーバーが切断された状態でローカル内部フェールオーバータイムベースソースを使用してntpqを実行すると、
* 192.168.a.b *this is the connected time server*
192.168.c.d *this is the disconnected time server*
127.127.1.0
その後、選択したピア（アスタリスクで表示）が切断され、数分後にntpqが報告します。
192.168.a.b *this has been disconnected*
192.168.c.d *this is still not yet connected*
* 127.127.1.0 *this is what I would expect*
最初のNTPサーバーが再接続され、ntpqは元の状態を報告します。
* 192.168.a.b *this has been reconnected*
192.168.c.d *this is still not connected*
127.127.1.0
次に、2番目のNTPサーバーに接続します。数分（3-4）後、ntpqが報告します。
x 192.168.a.b *this is still connected*
x 192.168.c.d *this is now connected for the first time in this test*
127.127.1.0
以前は「x」を見たことはありませんが、ntpプログラミングマニュアル、これはサーバーが「偽のラベル」であることを意味します。 「クロスアルゴリズムによってピアが無効なラベルで削除されました。」
質問：元のピアが選択されていないのはなぜですか？現在どのタイミングソースが使用されていますか？
その後、最初のサーバーの接続が切断されました。
その時点で、ntpqは実行されておらず、私たちはntpdが死んだことを知りました。だから私たちはntpサービスを再起動し続けました。
ntpqとntpdをもう一度実行し、ntpqが報告されるまで数分待ちます。
* 192.168.a.b *but this is not connected!*
+ 192.168.c.d *this is still not connected*
127.127.1.0
切断されたNTPサーバーが選択されたピアとして宣言されました！実行中で接続されている2番目のNTPサーバーは候補として報告されます。 「ピアは生存者であり、結合されたアルゴリズムの候補です。」
質問: 切断された NTP サーバが選択されたピアとして宣言されるのはなぜですか。現在どのタイミングソースが使用されていますか？
これらの一連のイベントは、単に初期失敗を強制できるかどうかを確認するためのものでしたが、実際にはそうではありませんでした。ただし、元の問題の原因が何であるかを示す可能性がある予期しない結果が発生しました。また、興味深いのは、これまでシステムがntp関連の問題を報告したり、元の失敗の他の症状を表示せずに中断することなく実行され続けることです。
最初のサーバーは市販のGPSベースのタイムサーバーです。 2番目のサーバーは、独自の別々のハードウェアの仮想マシンで実行されます（現在は他の詳細はありません）。