LinuxでNTPがシステム時間を調整したかどうかを確認する方法は？

18

私が実行しているリアルタイムのもののいくつかでトラブルを経験したマシンがあります。私が持っている1つのリードは、NTPデーモンが時間を移動し、誤ったタイムアウトを引き起こした可能性があることです。

NTPデーモンが実際にまったく時間を移動したかどうかを確認するにはどうすればよいですか？ログはありますか？/ var / log / messagesでNTPデーモンが再起動しますが、時間調整も必要かどうかわかりません。

明確にするために：イベント後、ログからそれを理解する必要があります。時間が調整されてから2日後になる場合があります。コマンドを実行して現在のステータスを確認しても効果はありません。

linux ntp

8

ntpdc -c sysinfoコマンドを使用して、ntpdステータスを照会できます。次のような出力が返されます。

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      338.44917 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  8:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.003998 s
authdelay:            0.000000 s

— ジャンヌ・ピッカライネン
ソース

4

ドリフトファイル（/ var / lib / ntp / drift）は、ローカル時間と、接続されたタイムサーバーに基づいてntpdによって計算された時間との差を測定しません。

代わりに、ローカルクロックの推定ドリフト（周波数誤差）（ppm）です。この値はntpdによって1時間に1回更新され、時間の経過とともに減少することはありません。

私が知る限り、再起動後に値がntpdによって使用され、ローカルクロックがどれほど間違っているかを推定します（マシンの電源がオフの場合でもローカルクロックは実行されます）。

例：ファイルの内容：5マシンの電源が1日切れた（86400 s）86400の5 ppmは0.432 =>ローカルクロックは「将来」0.432 s

ポイントは次のとおりです。-ntpdは、開始直後に最初の近似補正をローカル時間（-0.432 s）に適用できるようになりました-ntpdは、ローカルクロックがどのくらい間違っているかをすぐに認識します（この例では5 ppm）

（Sirexのコメントにコメントすることはできませんので、新しいコメントを追加しました）

— マーティン・シュニーワイス
ソース

3

ドリフトファイルに値が必要です。その場所は/etc/ntp.confにあります

例： "driftfile / var / lib / ntp / drift"

このファイルは、クロックが本来あるべき位置からどれだけ離れているかを記録するために使用され、ゆっくりとntpは時間の経過とともにこの値を下げる必要があります。-システムでタイムスタンプの問題が発生する可能性があるため、一度に実行しません。

— シレックス
ソース

これは良い情報です、ありがとう。それでも、時間が移動すると、これは0になり、情報が失われます。ntpはメッセージをログに記録して、完了したことを通知しませんか？

— n-

3

ntpq -nc peers すべてのピアとの同期ステータスが表示されます。

— ビルソー
ソース

2

申し訳ありませんが、これは古いスレッドです-ここでルールを破っていないことを願っています:)

/etc/ntp.confには、次のような行があります。

#statsdir /var/log/ntpstats/

説明では、統計を記録するためにこの行のコメントを外すように指示されています。サーバーにntpを設定しただけなので、何がログに記録されるのかわかりませんが、ここで同じ情報を探すことになりました。

— dsl101
ソース