NTPDが引き続き更新を試みるのはなぜですか?

NTPDが引き続き更新を試みるのはなぜですか?

何も追跡できない奇妙な問題があります。しかし、経験が足りなくて明らかなものを見逃しているようです。

ntpdコンピュータ(Debian TowerとRaspbian)の時間が正確であるにもかかわらず、サービスがインターネットにアクセスしようとする理由を理解するのが困難です。私の考えでは、デーモンが継続的な試みではなく更新をスケジュールするように設計されているようです。

デフォルトでは、ルーターのアクティブな接続を確認するたびに、常に各LinuxボックスでNTPサーバーへの接続が3つ以上見つかり、時には合計15以上の確立された接続が見つかります。

ルータへの接続を切断した場合(すべての接続をクリア)、新しい試行を実行する前の待ち時間は明らかに非常に短いですが、想定された更新プロセスが完了するのを待つ時間は決して「作業を完了する」ことができなくなります。になります。

推測できるように(RPiにRTCはありません)、Raspbianに現在時計があるという単純な事実は、ある時点で更新が完了し、時間が設定されたことを意味します。

これがどれほど迷惑になるかを説明する必要はありませんが、前述したように、残念ながら私は原因を正しく追跡することができる知識がありません(おそらくソフトウェアツールを意味します)。

  • この問題に関する手がかりを見つけるためにどのような措置をお勧めしますか?
  • 構成エラーが原因である可能性がありますか?
  • それともこれは正常な行動ですか?

貴重なフィードバックをお寄せいただきありがとうございます。

ベストアンサー1

NTPデフォルトでは、参加者(実行中のシステムを含むntpd)は時間同期プロトコルを使用して定期的にメッセージを交換します。これは、システムからさまざまなNTPサーバーへの複数の接続を見ることが完全に正常であることを意味します。ntpq次のコマンドを実行して使用して、これについて詳しく学ぶことができますpeers

ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
-ntp-3.arkena.ne 138.96.64.10     2 u  837 1024  377   45.882   -0.773   0.748
-ntp.univ-angers 145.238.203.14   2 u  684 1024  377   55.914    1.742   0.605
+regar42.fr      195.154.10.106   4 u  702 1024  377   47.394   -0.125   1.287
*dedibox.demonge 195.83.222.27    2 u  693 1024  377   45.821    0.628   2.468
-infidel.e-lista 145.238.203.14   2 u  699 1024  375   50.725    0.767   1.069
+195-154-10-106. 175.122.215.45   3 u  460 1024  377   46.420    0.052   2.269

(または単にntpq -pシェルから)。

時折ワンタイムクロック同期を実行する場合は、この機能を使用するのが最善ですntpdate

おすすめ記事