ntpdにntp.confファイルで指定されたサーバーアドレスを繰り返し参照させる方法はありますか？
マシンに次のようなntp.confファイルがあるとします。
ドリフトファイル<path-to-drift-file>
サーバー<NTP-server-1>
サーバー<NTP-server-2>
サーバー<NTP-server-2>
何らかの理由で、NTPサーバーがすべてのサーバーへの最初のクエリで実行されていない場合を考えてみましょう。ntpdにこれらのソースのクエリを繰り返し実行させることはできますか（つまり、サーバー1からサーバー3を再度参照してください）。ループ内）？どうすればよいですか？
編集：マシンのntp.confで指定されたサーバーのリストから、実際の時間同期を引き起こしたサーバーを定量的に判断する方法はありますか？
/etc/ntp.confで定義されているすべてのサーバーは、時刻の同期に使用されます。アルゴリズムはすでに複数のソースを処理しているため、サーバーを「ループ」させる必要はありません。
Ntpdプログラムは、指定されたポーリング間隔で1つ以上の構成済みサーバーとメッセージを交換することによって動作します。
差出人： man ntpd
これは、コマンドラインでntpq -pを実行して、ピアとそのステータスを表示することで確認できます。
次のような出力が表示される場合があります。
remote refid st when poll reach delay offset disp
========================================================================
+128.4.2.6 132.249.16.1 2 131 256 373 9.89 16.28 23.25
*128.4.1.20 .WWVB. 1 137 256 377 280.62 21.74 20.23
-128.8.2.88 128.8.10.1 2 49 128 376 294.14 5.94 17.47
+128.4.2.17 .WWVB. 1 173 256 377 279.95 20.56 16.40
出力については、マニュアルページでも説明されています。しかし、時間をかけて私はいくつかのメモを集めました：
remote：ntp.confファイルで指定されたピア
* =現在の時刻ソース
＃=ソースが選択され、距離が最大値を超えています
o =ソースが選択され、Pulse Per Second（PPS）が使用されました
+ =ソースが選択され、最終セットに含まれています
x =ソースの偽のティッカー
。 =候補リストの最後から選択されたソース
-=クラスターアルゴリズムによって破棄されたソース
空白=ソースは高い層を破棄し、正気を失ったrefid：リモートソースの同期ソース
stratum：ソースの層レベル
t：利用可能なタイプ
l =ローカル（GPS、WWVBなど）
u =ユニキャスト（最も一般的）
m =マルチキャスト
b =ブロードキャスト
-= netaddrwhen：最後の応答から経過した秒数
poll：ソースのポーリング間隔（秒単位）
reach：ソースへの到達の成功/失敗を示し、377回のすべての試行が成功しました
delay：応答を受信するためのラウンドトリップ時間をミリ秒単位で示します
offset：クライアントサーバーとソースの間の時間差をミリ秒単位で示します
disp/jitter：2つのサンプル間の差をミリ秒単位で示します
最後に、最後の質問に答えます。
マシンのntp.confで指定されたサーバーのリストから、実際の時間同期を引き起こしたサーバーを定量的に判断する方法はありますか？
（*）で示されたホストは、現在選択されているタイムソースです。これは、ポーリング中に変更される可能性があります。
Ntpdは、起動時に、構成されているすべてのサーバーにクエリを実行し、階層が最も低いサーバーを選択します。それが失敗した場合、それは自動的に次のサーバーにフォールオーバーします。では、なぜそれを変更したいのですか？
編集：周りをチェックした後、実際にはクロック同期を高速化することを目的としたiburstパラメーターに関する情報を見つけました。ここでの違いは、どのサーバーにも到達できない場合にntpd-serverを終了させることです。これを悪用して、ntpdのインスタンスが常に実行されていることを確認できます。たとえば、ウォッチドッグやcronによって時々実行される単純なスクリプトを使用できます。
残念ながら、到達可能なサーバーがない場合のntpdのデフォルトの動作を理解できませんでした。サーバーがDNSで解決されない場合（例： このバグ ）または インターフェースがダウンする の場合の動作について多くの参考資料を見つけましたが。