NTPがリモートサーバーではなくローカルに同期するのはなぜですか？
だから、私は現在のNTP設定をデバッグしようとしています、そして彼が私の単一の設定されたサーバーからのオフセットが3秒以上であり、調整していないことを発見しました。でのアスタリスクntpqの出力は、システムが10.130.33.201サーバーではなく、システム自体と同期していることを示しているようです（これは、すべてを同期するシステム上の別のLinuxボックスです）。
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.130.33.201 LOCAL(0) 9 u 49 64 377 0.242 -3742.2 1.049
*LOCAL(0) .LOCL. 10 l 2 64 377 0.000 0.000 0.001
そして、これは私のntp.confファイルです。他の誰かが書いたので、すべてが正しいかどうかは100％わかりません。
server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift
restrict -4 default nomodify nopeer notrap
restrict -6 default ignore
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
私はバーストとiburstとminpoll/maxpollについて読んだので、それらは必要ないかもしれないと思いますが、それは私の現在の問題とは関係ないと思います。
また、デプロイ方法が原因で、その構成ファイルを変更するには多くの作業が必要になるため、実際に変更する必要のあるものがないことを願っています。これがNTPのしくみを理解していない場合の例です。
編集-
だから、これは この質問 の複製であるように見えますが、ポスターが十分な答えを得たとは思わないので、私はなぜ知りたいのですか？ 現地時間がサーバーよりも優先されています。また、以下の回答の1つに従って、configのサーバー行でpreferキーワードを使用して再起動しようとしましたが、効果がなかったようです。
他の質問への回答が示唆しているように、構成内のすべての「ローカル」行を削除すると、サーバーに到達できない場合はどうなりますか？ NTPは死ぬのですか、それとも試してみますか？
重要な編集-
通常、10.130.33.201（「サーバー」）はインターネットにアクセスできず、使用するGPSタイムソースもありません。重要な部分は、システム上のすべてのデバイスが、実際の時刻がどれほど正確であるかに関係なく、サーバーと同じ時刻であることです。
そこで、何が起こるかを確認するために、NTPプールサーバーの1つをサーバーの構成ファイルに追加して、ローカルからではなく、そこから時間を取得できるようにしました。 NTPタイムサーバーから時間を取得します。
それを行った後、クライアントはLOCAL（0）よりもサーバーと同期するようになりました
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.130.33.201 38.229.71.1 3 u 58 64 377 0.216 715621. 1.001
LOCAL(0) .LOCL. 10 l 18 64 377 0.000 0.000 0.001
新しい質問-サーバーがローカル（指定された元の例）を使用している場合、クライアントは「10.130.33.201はLOCAL（0）を使用しています。うーん、LOCAL（0）サーバーも使用しています- -10.130.33.201で同じ情報を取得するのではなく、直接使用します。
それは事実ですか？彼らは誤ってLOCAL（0）である「ソースに直接」移動しようとしていますか？サーバーでLOCAL（0）から時間を取得する必要があり、クライアントでサーバーから時間を取得する必要があります。現在、クライアントの構成ファイルから「ローカル」サーバーを削除することが唯一のオプションですが、これが発生している理由を理解したいと思います。可能な場合は、構成の変更を避けてください（構成の変更は、私たちの環境...）。
また、 this は、適切な回答がない別の重複のように見えます。
NTPサーバーが1つしか構成されていない場合、アルゴリズムは誰を信頼するかが完全にわかりません。リモートホストの方が層が低い場合でも、アルゴリズムは現地時間の方が信頼できると考えています。
preferキーワードをserverステートメントで使用して、それを優先的なタイムソースとして設定してください。
編集-
だから、これはこの質問の複製のようですが、ポスターが十分な答えを得たとは思わないので、サーバーよりも現地時間が好まれている理由を知りたいです。
本当に十分な答えを得るには、非常に複雑なアルゴリズムの仕組みを掘り下げることになります。ドキュメントにはtooも特定されていませんが、ホワイトペーパーや仕様書がそこにあるはずです。
他の質問への回答が示唆しているように、構成内のすべての「ローカル」行を削除すると、サーバーに到達できない場合はどうなりますか？ NTPは死ぬのですか、それとも試してみますか？
NTPデーモンは停止または停止しませんが、リモートサーバーへの到達に失敗した後、同期時間を終了します。このため、ベストプラクティスでは、最低3台のリモートサーバーを使用し、ネットワークから切断されていない限り、LCL。2つしかなく、それらが一致しない場合は3つサーバーが推奨されます。3つ目のサーバーは、アルゴリズムが偽のサーバーを排除するのに役立ちます。
最後に、driftfileを定義していないことに気づきました。これは役に立ちますか？
オフセットの間隔（システム時間とNTP hosttime）の差）がNTP 。
私のおすすめ、
1. Stop the NTP service
2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
3. Start the NTP service
その後は問題ありません。
これは古いことは知っていますが、あなたは正しいと思います。 ntpdの問題をデバッグする方法を示す人はいません。実行可能であることがわかりました。
ローカルおよび上流サーバーでのLOCAL（0）の使用が問題である可能性があると疑ったとき、あなたは正しい軌道に乗っていたと思います。
それは確かに私が同様の問題を抱えていた4台のサーバーのタイムアイランドにありました。これらはすべて互いに同等になるように設定されているため、おそらく別の問題です。
最初に、過去数年のntpdバージョンでサポートされているOrphanモードと呼ばれるタイムアイランドを処理するより良い方法があります。
最初は、4つのサーバーすべてが同じ10の層を持ち、ローカルクロックを優先しました。私はそれを修正しましたが、それでも彼らは自分のローカル時計を好んでいました（層は重要であるように見えます）。
私はntpqコマンドpe（peer）を使用しました。これは、rvが何が起こっているかに関するハンドルを取得するためです。サーバーが情報をダンプするには、関連付け番号でrv（readvar）を使用する必要があります。 peとasは同じインデックスでソートされているように見えるため、as番号をそのように取得できます。サーバーが気に入らない場合は値rejectを示すかもしれないconditionというフィールドがあります。
Rv出力には、flashというフィールドがあります。すべてが順調であれば、これはゼロになります。そうでない場合は、問題のビットマスク（16進数で表示）です。彼らはここで調べることができます：
私が持っていた問題は0800 peer_loopでした。時計の再設定が重要であることがわかりました。ローカルクロックとリモートサーバーの両方からLOCAL（0）を見ると、ntpdはループがあると考えていました。デビッドミルズは、comp.protocols.timeの投稿で、「NTPでループを回避する方法」を確認しています（リンク数の上限に達しました、申し訳ありません！）
Refid引数を使用して一意のrefidを設定することはできませんでした-受信者ではLOCAL（0）として表示されます。
機能しているように見えたのは、ローカルドライバーに一意のインスタンス番号を使用することでした。 127.127.1。[0-3]。サーバーとファッジ行の両方で同じIDを使用してください。これを行ったとき、サーバーは通常、ローカルクロックを通常使用する最下層サーバーに同期しました。ただし、ソースとして使用していた他のサーバーの1つを使用しようとすることもあります。しかし、時代は同期し、そのようにとどまっているようです。
おそらく手遅れになるかもしれませんが、NTPはロジックとトラブルシューティングに適しています。表示するまで提供します。試行錯誤で答えに到達するのに何時間もかかった後、後でドキュメントを見つけました。
ローカルサーバーとしての10.130.33.201のストラタムは9であり、これ（9 + 1 = 10）から計算されたローカルストラタムは、ストラタム10のローカルLOCALサーバーと競合します。ローカルLOCALストラタムにはネットワーク遅延やジッターがないため、リモートのものよりもntpdの方が少し良く見えるかもしれません。
この構成を機能させるには、「マスター」ローカルサーバーを9未満の層に設定します。層1のサーバーまで追跡可能な時間を優先する場合は、少なすぎません。