サーバーがタイムソースとして使用されていない場合、ntpdをLocal（0）に同期させる理由はありますか？
CentOSリリース5.8の実行
私は修正したサーバーで時間ドリフトの問題がありました-それはhwclockを同期していなかったので、再起動時にntpは1000秒以上オフになり、時間を同期しませんでした。
問題を調査しているときに、ntpdがLocal（0）に定期的に同期していることに気付きました。
このサーバーをタイムソースとして使用する予定がない場合に、ntpdをLocal（0）と同期するように設定する理由はありますか？
「答え」-他のタイムサーバーへの接続が失敗したときにこのサーバーをローカルタイムサーバーとして使用する場合を除き、Undisciplined Local Clockを使用する必要はありません。
Ntpdからのログメッセージ：
Jul 20 03:47:49 localhost ntpd[5441]: synchronized to 110.14.8.1, stratum 3
Jul 20 04:21:06 localhost ntpd[5441]: synchronized to LOCAL(0), stratum 10
Jul 20 04:38:09 localhost ntpd[5441]: synchronized to 110.14.8.1, stratum 3
Jul 20 04:55:26 localhost ntpd[5441]: synchronized to LOCAL(0), stratum 10
ntpd.conf：
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 10.4.58.21
# 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
ローカル同期を無効にしますが、ローカル同期が発生している理由を知りたいと思います。同じサブネット上に一時的なタイムサーバーを配置しましたが、ntpdは引き続きローカル時間に同期します。 （*考えられる答え：ntpdc -c sysinfoは、ntpサーバーのstartumが11であることを示しています。これは、ntpdにローカルに使用するように指示した10よりも悪いです。ntpdのソースを確認する時間*）
Jul 24 17:11:32 localhost ntpdate[5432]: step time server 227.220.222.220 offset 1629.764734 sec
Jul 24 17:11:32 localhost ntpd[5434]: ntpd [email protected] Fri Nov 18 13:21:21 UTC 2011 (1)
Jul 24 17:11:32 localhost ntpd[5435]: precision = 1.000 usec
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface wildcard, ::#123 Disabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface eth0 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface lo, ::1#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface lo, 127.0.0.1#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface eth0, 192.12.140.55#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: kernel time sync status 0040
Jul 24 17:11:32 localhost ntpd[5435]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Jul 24 17:14:48 localhost ntpd[5435]: synchronized to LOCAL(0), stratum 10
Jul 24 17:16:55 localhost ntpd[5435]: synchronized to 192.12.140.200, stratum 3
Jul 24 20:11:06 localhost ntpd[5435]: synchronized to LOCAL(0), stratum 10
Jul 24 20:20:50 localhost ntpd[5435]: synchronized to 192.12.140.200, stratum 3
ntpdは、ローカルハードウェアクロックの同期を担当しません。通常、これを行うために提供されるプログラムがあります。 Ubuntuでは、プログラムはhwclockです。起動時にシステム日付を設定し、シャットダウン時に更新して使用されます。
私は通常、ローカルのタイムソースとしてハードウェアクロックのみを構成しますNTP=タイムサーバー。クライアントで構成する場合は、より高い階層に設定して、タイムサーバーが到達可能であれば時間の権限。
ntpdを使用してローカルクロックと同期している場合は、ハードウェアクロックをUTCに設定し、ブート時にクロックからUTCを期待するようにシステムを構成します。残念ながら、これはWindowsへのデュアルブートの場合はうまく機能しません。その場合は、ローカルクロックをタイムソースとして使用しないでください。
出力から、断続的な外部タイムソースが1つあるように見えます。これにより、ハードウェアクロックを前後に切り替えることができます。到達可能であっても、外部のタイムソースは独自の同期を失っており、タイムソースと見なされない可能性があります。常時ネットワークに接続している場合は、タイムソースをさらに2つ追加します。断続的なネットワーク接続がある場合は、ハードウェアクロックの設定を修正するか、ハードウェアクロックをソースから削除してください。
ハードウェアクロックが起動時に1000秒以上ずれているという事実は、考えられる2つの問題のいずれかを示しています。
- ハードウェアクロックが、ブートシーケンス中にシステム時刻を設定するソフトウェアが予期するタイムゾーンに設定されていません。
- システムの電源がオフのときにCMOS=を実行し続けるために使用されているバッテリーが切れているか、切れています。
ntpdコマンドに-gオプションを追加することで、起動時に同期の問題を解決できます。
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
これは、公式サーバー（これ以上）に到達できない場合のフォールバック時間ソースとして使用されます。ドリフトファイルを有効にした場合、ドリフトファイルにはローカルクロックに対するリアルタイムの修正値が含まれるため、これにより時刻が同期されます。
同じハードウェア上で実行されている他のシステムがローカルクロックを同期する場合は、ローカルクロックに同期することをお勧めします。例：Host1で、VM1はntpを実行し、いくつかのパブリックntpサーバー（つまり、層3）と同期します。 Host1、VM2、VM3、VM4、...でntpを実行し、ローカルクロックに同期します。
VM1が実行されている限り、すべてが問題ないはずです。
IMHO、ntp通常同期を実行ハードウェアクロックを「小さなステップで」、「継続的に」考えるので、シャットダウン時に「hwclock -wu」は必要ありません。
ローカルタイムソースに同期することは、実際には何も存在しないときに、時計を混乱させる優れた方法です。あなたは難しい方法を発見しました（私が少し前にしたように）。これは、GPS、原子時計、または物理的にマシンに接続されている関連機器がある状況を対象としています。そのようなハードウェアがない場合は、無効にしてください。