GNU/Linux >> Linux の 問題 >  >> Cent OS

CentOS / RHEL 7 :NTP / chrony の問題のトラブルシューティングに関するヒント

chrony サービスは時刻を変更しません
よくある誤解は、chrony サービスが NTP サーバーによって提供された時刻に時刻を設定しているというものです。これは正しくありません。実際には、NTP サーバーからの応答に基づいて、chrony がシステム クロックを速くしたり遅くしたりするだけです。このため、時刻が間違っていて NTP サーバーが動作していても、時刻がすぐに修正されないことがあります。

chrony が時刻を設定する時刻のみ

chrony サービスが開始すると、/etc/chrony/chrony.conf にいくつかの設定があります。 特定の条件が発生した場合に実際に時刻を設定するように指示するファイル:

# Force system clock correction at boot time.
makestep 1000 10

つまり、開始後の最初の 10 回の測定で、時間が 1000 秒以上ずれていることを chrony が検出すると、クロックが設定されます。

便利なコマンド

以下は、chrony 関連の問題のトラブルシューティングに使用できる便利なコマンドです。

# chronyc tracking  
# chronyc sources
# chronyc sourcestats
# systemctl status chronyd
# chronyc activity
# timedatectl

chronyd のステータスを確認する

chronyd デーモンのステータスを確認するには:

# systemctl status -l chronyd
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2016-08-12 13:22:22 IST; 1s ago
  Process: 33263 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 33259 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 33261 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─33261 /usr/sbin/chronyd

Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Starting NTP client/server...
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Started NTP client/server.

chronyc ソース コマンド

chronyc ソースの実行 -v システムで構成されている NTP サーバーの現在の状態を示します。以下は出力例で、ntp.example.com がオンラインの有効なサーバーとして表示されます:

# chronyc sources -v
210 Number of sources = 1

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = OK for sync, '?' = unreachable,
| /                'x' = time may be in error, '~' = time is too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||                                                /   xxxx = adjusted offset,
||         Log2(Polling interval) -.             |    yyyy = measured offset,
||                                              |    zzzz = estimated error.
||                                   |           |                         
MS Name/IP address           Stratum Poll LastRx Last sample
============================================================================
^* ntp.example.com          3    6     40    +31us[  -98us] +/-  118ms

「*」以外のソース状態は、通常、NTP サーバーに問題があることを示していることに注意してください。

ソースの状態「~」は、時間が変動しすぎることを意味します
ソースの状態が「~」の場合 '、おそらくサーバーにアクセスできることを意味しますが、時間が変動しすぎます.これは、サーバーの応答が遅すぎるか、応答が遅くなったり速くなったりする場合に発生する可能性があります。サーバーへの ping の応答時間をチェックして、応答が遅いか変動するかを確認できます。この状態は、サーバーが遅すぎる仮想マシンで実行されている場合にも発生し、タイミングの問題が発生します。

Chrony のチェックと 1 時間ごとの再起動

1 時間に 1 回、chrony サービスは chronyc sources -v の出力をチェックします コマンド、スクリプト /usr/sbin/palladion_chrony_healthcheck を実行して /usr/sbin/palladion_check_chrony を実行します そしてその出力をチェックします:

  • /usr/sbin/palladion_check_chrony が 1 を返した場合 – オンラインのソースがなかった (ソース状態 ='*' のソースがない) ことを意味するため、サーバーのステータスを再初期化するために chrony が再起動します
  • /usr/sbin/palladion_check_chrony が 0 を返した場合 – これはすべて問題がないことを意味します。有効なオンライン ソースが既にあるため、chrony を再起動する必要はありません
# cat /etc/cron.d/chrony
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#
# Check chrony every hour and restart if necessary.
#
16 * * * *     root    /usr/sbin/palladion_chrony_healthcheck

Chrony ログ

トラブルシューティングに使用できるいくつかの chrony ログがあります。それらのほとんどは /var/log/chrony/ にあります .最新のファイルが常に *.log ファイルであるとは限らないことに注意してください。 *.log.2 または *.log.3 ファイルでさえ、より新しいファイルである場合があります。以下は、最近のもので並べ替えてファイルを一覧表示する例です:

# ls -lisaht  /var/log/chrony/
total 1.5M
3801115 580K -rw-r--r--  1 root root 574K Oct 21 14:56 measurements.log.3
3801131 544K -rw-r--r--  1 root root 540K Oct 21 14:56 statistics.log.3
3801166 356K -rw-r--r--  1 root root 350K Oct 21 14:56 tracking.log.3
3801089 4.0K drwxr-xr-x 16 root root 4.0K Oct 21 00:01 ..
3801114 4.0K drwxr-xr-x  2 root root 4.0K Oct 21 00:01 .
3801128    0 -rw-r--r--  1 root root    0 Oct 21 00:01 tracking.log
3801110    0 -rw-r--r--  1 root root    0 Oct 21 00:01 measurements.log
3801120    0 -rw-r--r--  1 root root    0 Oct 21 00:01 statistics.log
3801167    0 -rw-r--r--  1 root root    0 Oct 20 00:01 tracking.log.1
3801165    0 -rw-r--r--  1 root root    0 Oct 20 00:01 statistics.log.1
3801159    0 -rw-r--r--  1 root root    0 Oct 20 00:01 measurements.log.1
............

IP アドレスを入力して NTP サーバーを 1 つだけ設定してみてください

これまで 2 つ以上の NTP サーバーを使用していた場合 (それらが設定されているため、または別の IP アドレスで解決される FQDN を入力したため)、IP アドレスを 1 つだけ入力して 1 つの NTP サーバーを設定してみてください。これにより、NTP 関連の問題が解決する場合があります。

NTP サーバーとの通信のトレース

NTP サーバーが応答しているかどうかを再確認するには、サーバーを監視しながら、chrony と NTP サーバーの間のトラフィックを一定期間追跡することができます。
1. NTP ポート 123 で tcpdump を使用して pcap トレースを開始し、問題が発生するまで実行したままにします (シェル コマンドから切断した場合に停止しないように、「screen」または「nohup」で実行します)
2 .問題が再発したらすぐに、サーバーを DNS 名に設定してから、ギャップが再発するまでの履歴全体をカバーするシステム診断を取得します。これにより生成されるファイルが大きすぎる場合は、現在のデータのシステム診断を取得し、さらに /var/log/chrony/ からすべてのファイルと /var/log/syslog* という名前のすべてのファイルをコピーします。ステップ 1 で開始したトレースを忘れずに停止してください


Cent OS
  1. CentOS / RHEL 7 :Chrony V/s NTP (ntpd と chronyd の違い)

  2. CentOS / RHEL 7 :chrony をローカル クロックに同期する方法

  3. CentOS / RHEL 7 :タイムゾーンを変更する方法

  1. ChronyでNTPを管理する

  2. CentOS / RHEL 6,7 での iSCSI の問題のトラブルシューティング方法

  3. CentOS/RHEL での一般的な GUI/X-Window の問題のトラブルシューティング

  1. CentOS / RHEL 7 :chrony を使用して NTP を構成する

  2. CentOS / RHEL 7 :NTP を有効にして、新規インストール後に起動時に開始します (chrony を無効にします)

  3. CentOS / RHEL 7 で NTP サーバーとクライアントを構成する方法