サーバーの時間は7時間オフでした(date
が正しいタイムゾーンを示していても、午前10時ではなく午前3時でした)。 ntpqの出力は次のとおりです。
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xx.xxx.xxx.x.ar xxx.x.xx.xx 2 u 72 1024 177 6.516 2520657 1650156
ntp.xxxx.ac.uk xxx.xxx.xxx.x 2 u 7h 1024 377 14.039 2520655 1347346
xxx.xxx.xxx.xx xxx.xxx.xxx.x 2 u 114 1024 377 5.449 -18.941 2130343
ns1.xxxxxxx.com xxx.x.xx.xx 2 u 148 1024 377 8.050 2520655 1650156
時間は以下によって修正されました:
ntpdate -u 0.europe.pool.ntp.org
しかし、それは数日後に再び起こりました。 ntpq -p
の2行目は、最後に受信したパケットから7hであると考えています。しかし、それが理由である場合、ntpが他のサーバーを使用して時刻を同期しなかったのはなぜですか?
何が起きたの?これが再発しないようにするにはどうすればよいですか?
編集もう1つの考慮すべき点は、それがVMであることです。 VMが何らかの一時停止状態だった可能性はありますか?
vmware-toolbox-cmd timesync status
が無効になっていることに注意してください。
Ntpdが起動したら、ホストとリモート間の時間差をチェックしますNTPサーバー。その差が大きすぎる場合(通常10〜15分)、それはrefuse何かを変える。
ntpdate
を実行すると、ntpd自体が行うことのミリ秒以内に時間をもたらす、ワンショットのより単純なSNTP実装を効果的に使用します。これで、ntpdサービスを再起動すると、サーバーが同期されているはずです(ntpq -p
で確認してください)。
単純な永続的な解決策は、ブートプロセスの早い段階で最初にntpdate
を使用し、しばらくしてから「実際の」ntpデーモンを起動することです。ちなみに、CentOS 6.xと7.xはまったく同じことを行います。ntpdateとntpの両方をインストールすると、前者はブートプロセスの早い段階で使用され、後者は後の段階で使用されます。
過度のジッター/オフセットが原因でntpが同期に失敗したようです。国の近くにあるntpサーバーの別のプールを試すことをお勧めします。
これらのIPはパブリックで十分に文書化されたサーバーであるため、ステータスのIPを難読化する必要はありません
VMwareでマシンを実行している場合は、次も確認してください http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf およびntpを維持物理サーバーのクロックが調整されています。
「考慮すべきもう1つのことは、それがVMであることです。VMが何らかの一時停止状態だった可能性はありますか?」
はい、VMwareツールが同期無効に設定されている場合でも、VMwareは一時停止後にクロックを再同期します
VMware Toolsの定期的な時刻同期をオンにするかどうかに関係なく、時刻同期は特定の操作の後に発生します。