CentOSバージョン5.8の実行
サーバーの時間ドリフトの問題を修正しました。 hwclockを同期していないため、再起動時にntpが1000秒以上オフになり、時刻が同期されませんでした。
問題の調査中に、ntpdが定期的にLocal（0）と同期していることがわかりました。
このサーバーがタイムソースとして使用されていないときにLocal（0）と同期するようにntpdを設定する必要がある理由はありますか？
「回答」 - 別のタイムサーバーへの接続が失敗したときにこのサーバーをローカルタイムサーバーとして使用したい場合を除き、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 statsは、ntpサーバーが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
答え1
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
これは、公式サーバーにアクセスできない場合の代替タイムソースとして使用されます（詳細）。ドリフトファイルにはローカルクロックのリアルタイム修正が含まれている必要があるため、ドリフトファイルを有効にした場合は時刻を同期したままにすることもできます。
答え2
ntpdローカルハードウェアクロックの同期を担当しません。通常、これを実行するためのプログラムが提供されます。 Ubuntuでは、プログラムはhwclock起動時にシステム日付を設定し、終了時に更新するために使用されます。
私は通常、ハードウェアクロックをローカルNTPタイムサーバーのタイムソースとして設定します。クライアントでこれを構成する場合は、タイムサーバーがアクセス可能である場合は、時間のアクセス許可を維持するようにより高い階層に設定します。
ローカル時計と同期するには、ntpdハードウェア時計をUTCに設定し、起動時に時計がUTCになるようにシステムを設定します。残念ながら、この方法はWindowsでデュアルブートすると正しく機能しません。この場合、現地の時計を時間源として使用しないでください。
出力結果によれば、断続的な外部時間源によりハードウェアクロックが前後に変化することがわかった。アクセス可能であっても、外部タイムソースは自己同期が失われ、タイムソースと見なされない可能性があります。インターネット接続が安定している場合は、タイムソースを追加してください。ネットワーク接続が断続的に切断される場合は、ハードウェア時計の設定を変更するか、ソースであるハードウェア時計を削除してください。
起動時にハードウェアクロックが1000秒以上ずれるという事実は、次の2つの問題のうちの1つがある可能性があることを示しています。
- ハードウェアクロックは、起動シーケンス中にシステム時間を設定するソフトウェアによって予想される時間帯には設定されません。
- システムの電源が切れたときにCMOSを実行し続けるために使用されるバッテリーが使い果たされたか、またはほとんど使い果たされました。
-gこのオプションをコマンドに追加すると、起動時に同期の問題を解決できますntpd。
答え3
現地時間ソースと同期することは、現地時間ソースが実際に存在しないときに時計を制御できないようにするための素晴らしい方法です。あなたはこれを難しい方法で見つけます（私がしばらく前にやったように）。これは、GPS、原子時計、または関連機器が機械に物理的に接続されている場合に適用されます。該当するハードウェアがない場合は無効にしてください。
答え4
同じハードウェアで実行されている他のシステムがローカルクロックを同期している場合は、ローカルクロックと同期することをお勧めします。例：Host1では、VM1はntpを実行し、一部のパブリックntpサーバー（例：レイヤ3）と同期します。 Host1、VM2、VM3、VM4...でntpを実行し、ローカルクロックに同期します。
VM1が実行されている限り、すべてが問題ありません。そうですか？
IMHO、通常ntp同期するかどうかハードウェアクロックは「ステップ」で、「連続的に」と思うので、終了するときに「hwclock -wu」は必要ありません。