サーバーでntpdを実行しています。他のマシンのサーバーになる機能をコメントアウトした以外は、すべてデフォルト設定です。
# restrict -4 default kod notrap nomodify nopeer noquery
# restrict -6 default kod notrap nomodify nopeer noquery
restrict default ignore
ntpdate -q ntp.ubuntu.com
、マシンのクロックが7秒ずれていると言われました。
どうしたの?何が起こっているのかをどのように診断できますか?オンにできるログはありますか?
詳細#1
# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
91.189.94.4 193.79.237.14 2 u 30 64 7 108.518 -0.136 0.361
詳細#2
これが私が質問したときの様子です:
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec
そして、ntpdを数回再起動した後の現在の様子を次に示します(これで修正されたと思います)。
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec
詳細#
Ntpをアンインストールし、openntpdをインストールして/usr/sbin/ntpd -d
、そして私はこのような出力を見ています:
reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s
これは、サーバーで時間を設定できないことをはっきりと示しています(ただし、通常のntpでは、時々更新されるようです...)。
詳細#4
私のVPSプロバイダーは言う:
最新のカーネルは、システムをdom0のクロックにロックするべきではありません。安全にするために、sysctl.confでxen.independent_wallclock = 1を設定できます。
正しいタイミング計算を行うために利用可能なCPUを必要とするVPSの問題にまだ対処していないと私は思います。
申し訳ありませんが、この質問をしてからしばらくして、デフォルトのベンダー(Ubuntu 10.0.4)構成でntpを再インストールし、数日間実行しました。これを書いている時点で、ntpdate -q ntp.ubuntu.com
は、私の時刻が0.000216秒以内で正確であることを示しています。だから、私が抱えていた問題は、カスタマイズされた構成にあったに違いありません(外部ホストがサーバーにクエリを実行できないようにしようとしており、ファイアウォールで既に実行しているため、あまり心配していません)。 Ubuntu 10.0.4 ntp.conf全体を以下に示します。コメントは削除されています。
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp.ubuntu.com
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
この構成がどのように改善されるかについてのフィードバックを歓迎します。
また、VPSプロバイダーと一緒にチケットを作成し、最善の方法についての詳細な推奨事項を尋ねました。このスレッドと、CPUの割り当てがタイミングの問題を引き起こす可能性があることを示すその他のドキュメントを示しました。彼らが言ったことはここにあります:
最新のカーネルは、システムをdom0のクロックにロックするべきではありません。安全にするために、sysctl.confでxen.independent_wallclock = 1を設定できます。これにより、サーバーインスタンスがホストサーバーの時計に従っていないことが確認されます。
そして:
この問題が仮想化環境に影響を与える正確な程度を誤解している可能性があります。NTP仮想化環境のクライアント。Xenホスト上の仮想化システムでの私の経験(Rackspaceでのセットアップなど)クラウド)割り込みを処理するための専用のシステムクロックがないことで受け継がれる不正確さは、高負荷のシステムでも数分の1秒に達します。このわずかな不正確さは、NTPサーバーの時間を1日に1回更新するように設定するだけです(またはそれよりも頻度を下げます)。
これをntp.confに追加して、ntpdでのロギングを有効にできます。
logfile /var/log/ntpd.log
ソース: ntp manual
Ntpdをオフにした場合、コマンドラインでクロックを更新できますか? ntpdateコマンドを実行して、次のようなエラーを受け取った場合:
# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted
これは、おそらくVPSを使用していることを意味します。その場合、システムクロックを変更することはできません。これは、ホストマシンでのみ実行できます。
Openntpdの代わりにntpdを使用したときに過去に見つけたもの:
Ntpdが正しく起動して実際に動作するには、localhostへのアクセスを許可する必要があります
restrict 127.0.0.1
restrict ::1
サーバールールにホスト名を使用できますが、それらのサーバーと通信するためにバックアップホールを開くことは、IPアドレスを必要とするrestrict
を使用することを意味するため、結局すべてにIPを使用する必要がありました。
restrict
を使用してサーバーへのアクセスを再開することについては言及していません。それが問題です。次のようなブロックを試してください。
# ntp.xs4all.nl
server 194.109.22.18
restrict 194.109.22.18
Ntpdは悪いアクターに対処するために多数決ルールの投票を使用しようとするため、複数のピアまたはサーバーが必要です。したがって、1つを失った場合でも過半数を維持できるようにするための最小値は4、できれば5です。
デフォルトのアクセスをロックダウンするには、次を使用できます。
restrict default notrust nomodify
まだクエリできるようにするために、私はrestrict default ignore
ntpd 4.2がnotrust
の意味を変更したときと同じです。 ため息
他の人にタイムサービスを提供していない場合は、おそらく通常のntpdの全機能を必要としないので、代わりにopenntpd
を検討する必要があります。 OpenBSDのスタッフによって書かれた、特権分離とはるかに単純な設定ファイルを使用した、はるかに最小限の実装です。それはntpdが提供する非常に正確な時間を提供しないと言われていますが、それは通常のサーバーまたはワークステーションにとって十分に十分です。
コメントの1つに、仮想ホストで実行しているとあります。この場合、vhostの時間の感覚は、vhostが実行されている実際のホストとvhost全体のビジー度の両方に依存するため、おそらくそれほど成功することはないでしょう。
使用する仮想化によっては、vhostは一定の時間内に割り込みの安定したシェアを取得しない場合があります。これにより、実際に発生しているよりも速く、または遅くクロックが実行されます。 ntpは、クロックが他の世界よりも固定レートが高速または低速であるという前提で変更を測定しようとしているため、この高速化および低速化はntp適合を与え、おそらく最終的にはあきらめ、結果をもたらしますそれ ntp -np
は、ntpが不適切と判断したタイムサーバーを示します。
これが当てはまる場合の最善の策は、おそらく力ずくであるrdate -s $server
頻繁に(6時間ごとなど)クロックを鼻で動かして、過度にずれないようにします。しかし、きめ細かい精度はおそらく手が届きません。
reach 7
ntpqの出力で、ntpdは約4分間しか実行できないことが示されています。 7は111バイナリです。これは、サーバーにすでに3回到達していることを意味します。 ntpは64秒ごとに到達し(poll
値)、最後の接触からすでに30秒(when
値)待機しました。
offset -0.136
は、システムがすでに同期されていることを示しています。 ntpdのみがまだサーバーをソースとしてマークしていません。少し時間をかけるだけで、小さな星が現れます。
したがって、実際にはntpdが同期していました。しかし、ntpdは通常(ntpdateのように)1回の大きなジャンプで同期しませんが、ゆっくりと時間を調整しようとし、数サイクルにわたって時間を安定させます。
PS:私は、質問が非常に古いことを認識しています。しかし、問題は永遠です。そして、他のすべての答えは私見を誤解させるだけです。 ntpdは、時刻を同期させるためにVMWareでも推奨されています。
私は自分のシステムを見つけて、ハードウェアクロックが正常なシャットダウンでシステムクロックと同期していない理由に戸惑いました。 sysconfigにNTP設定があり、それを行うには編集が必要です。
/etc/sysconfig/ntpd
:
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
これをyes
に設定しました。もちろん最初に、確実なNTPサーバーがあり、システムクロックが信頼できることを確認してください。
私はそれを知っていました-私のスキューは47秒で、私のHWクロックも47秒ずれていました。ビンゴ!私の最初の手がかりは、ログで見られるKerberosの失敗でした。 Kerberosと多くのNASは、クロックスキューが大きすぎると機能しません。
ごきげんよう!
vmwareでvhostを実行している場合は、次の記事を確認してください。役立つ情報 http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
ハイ.
このリファレンスを参照して、問題のトラブルシューティングに役立つかどうかを確認してください。
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:Ch24:_The_NTP_Server
ntpd.confファイルの内容、ntpq -pのようなデバッグコマンドの出力をポストすることができます。
そして、あなたの日付/時刻を確認しますか?
これを確認し、ntpdateとstartup ntpdを実行します。時刻は同期していますか?
願いを込めて