LinuxのNTP同期を確認するときは、最初にどの時刻同期デーモンが動いているかを特定してください。chronyならchronyc trackingとchronyc sources -v、systemd-timesyncdならtimedatectl statusとサービスログ、ntpdまたはNTPsecならntpq -pnを使います。サービス名や設定ファイルはディストリビューションで異なるため、すべてのLinuxへ同じコマンドやパスを当てはめてはいけません。
現在のRHEL 8/9系はchronydが標準で、Ubuntuは25.10以降chronyが既定です。Ubuntuのchronyはchrony.service、RHELではchronyd.serviceとして動きます。古い記事に多いntpd、/etc/ntp.conf、yum install ntpという手順を最初から実行すると、既存のchronyやsystemd-timesyncdと競合する可能性があります。
最初の判定表
| 実装 | 代表的なサービス名 | 主な確認コマンド | 代表的な設定場所 |
|---|---|---|---|
| chrony on RHEL | chronyd.service | chronyc tracking、chronyc sources -v | /etc/chrony.conf |
| chrony on Ubuntu | chrony.service | chronyc tracking、chronyc sources -v | /etc/chrony/chrony.conf、/etc/chrony/sources.d/ |
| systemd-timesyncd | systemd-timesyncd.service | timedatectl status、journalctl | /etc/systemd/timesyncd.conf、同名の.conf.d |
| ntpd / NTPsec | ntp.serviceまたはntpd.service | ntpq -pn | ディストリビューションのパッケージ文書で確認 |
表は代表例です。コンテナ、組み込みLinux、クラウドイメージ、派生ディストリビューションでは異なることがあります。設定変更の前に、OSのリリース情報、導入済みパッケージ、systemdユニットを確認してください。存在しないサービスを起動するために、別の時刻同期パッケージを追加する必要はありません。
NTP同期で確認すべき3つの状態
- サービスが動いているか。デーモンがactiveでも、時刻ソースを選べているとは限りません。
- 外部または内部の時刻ソースを選択できているか。到達性、測定数、ソース品質、認証の結果を確認します。
- アプリケーション要件を満たす誤差か。単にNTP service activeと表示されるだけでなく、オフセット、分散、最終更新時刻を確認します。
NTPv4は広く使われる標準プロトコルですが、すべての環境でミリ秒精度を保証するものではありません。ネットワーク遅延、時刻ソース、仮想化、CPU負荷、ハードウェアクロック、デーモン設定で精度は変わります。必要な精度を先に定義し、測定値がその基準に入っているかを判断します。
手順1：OSと稼働デーモンを特定する
最初にOS情報とsystemdの時刻状態を確認します。timedatectlはchronyが動く環境でも全体状態を表示できますが、詳細なソース品質はchronycで確認します。
cat /etc/os-release
timedatectl statustimedatectl statusでは、System clock synchronized、NTP service、Time zoneを確認します。System clock synchronizedがyesでも、どのサーバーを選んでいるか、誤差がどれほどかは分かりません。Time zoneが誤っているだけなら、UTCへの同期が正常でも表示時刻が違って見えます。時刻同期とタイムゾーンを別問題として扱ってください。
次に代表的なサービス状態を確認します。存在しないユニットではnot foundと表示されますが、それ自体は故障ではありません。activeなものを一つ特定します。
systemctl status chronyd
systemctl status chrony.service
systemctl status systemd-timesyncd
systemctl status ntp
systemctl status ntpd複数の時刻同期デーモンを意図せず同時に動かさないでください。Ubuntuではchronyが入っているとsystemd-timesyncdが時刻管理を譲る構成があります。このときtimesyncdが動いていないことだけを見て、故障と判断して起動すると競合の原因になります。
手順2：chronyの同期状態を確認する
chronyを使っている場合は、最初にtrackingを確認します。一般ユーザーでも実行できる構成が多く、設定を変更しない読み取りコマンドです。
chronyc tracking| 項目 | 確認内容 |
|---|---|
| Reference ID | 現在選択している参照元。ローカルモードや未同期の表示と混同しない |
| Stratum | 参照時計からの階層。小さいだけで品質が保証されるわけではない |
| Ref time | 最後に基準時刻を更新した時刻。古すぎないか確認 |
| System time | NTP時刻に対してシステム時計が進んでいるか遅れているか |
| Last / RMS offset | 直近および継続的な誤差の目安 |
| Root delay / dispersion | 参照経路の遅延と不確かさ |
| Leap status | Normalなら通常の同期状態。Not synchronisedなら次の診断へ進む |
次に、候補ソースと選択状態を確認します。名前解決の影響を減らして元の名前を表示したい場合は、環境のchronyバージョンで-Nオプションが使えるかをman chronycで確認できます。
chronyc sources -v
chronyc sourcestats -vsourcesの先頭にあるモード記号は、^がNTPサーバー、=がピア、#がローカル参照時計です。その次の状態記号では、*が現在選択中、+が結合対象、-が選択から外れたソース、xが他ソースと整合せずfalsetickerと判断されたもの、~が変動が大きいもの、?が到達不能・未同期・測定不足などで利用できないものを示します。
Reachは直近の応答履歴を8進数で示し、安定して応答すると377になります。ただし377だけで正常とは限りません。選択記号、LastRx、Last sample、trackingのLeap statusを合わせて確認します。複数ソースがすべて?なら、名前解決、ルーティング、ファイアウォール、サーバー側状態、NTS認証を調べます。
手順3：systemd-timesyncdを確認する
systemd-timesyncdが実際に時刻管理を担当している環境では、timedatectlとサービスログを使います。chronyがactiveなら、timesyncdが停止していることは正常な競合回避の可能性があります。
timedatectl status
systemctl status systemd-timesyncd
journalctl -u systemd-timesyncd --since '-1 hour'ログには、選択したサーバー、同期完了、名前解決や通信の失敗が記録されます。設定する場合の標準ファイルは/etc/systemd/timesyncd.confで、追加設定は/etc/systemd/timesyncd.conf.d/に置けます。ただし、設定変更前にNetworkManager、cloud-init、構成管理ツール、DHCPで時刻ソースが配られていないかを確認します。
手順4：ntpdまたはNTPsecを確認する
ntpqはntpdまたはNTPsecを監視するコマンドです。chronydへは使いません。実際にntpd系がactiveであることを確認してから実行します。
ntpq -pn-nはアドレスを名前へ逆引きせず表示し、DNS遅延の影響を減らします。行頭の*は選択されたシステムピア、+は結合対象です。reach、delay、offset、jitterを確認します。古い記事の表示例をそのまま正常値とせず、導入しているNTPsecまたはディストリビューションのmanページで列と記号を確認してください。
同期しない場合の安全な分岐
サービスはactiveだが同期していない
chronyならtrackingのLeap statusとsourcesの記号、timesyncdならjournal、ntpd系ならntpq -pnを確認します。設定ファイルをすぐ書き換えず、最後に正常だった時刻、ソース名、LastRx、reach、エラーを記録します。NTPサーバー自身が未同期なら、クライアントから到達できても選択されません。
名前解決または通信に失敗する
pingだけではNTPを確認できません。pingはICMPの応答であり、UDP 123やNTS鍵交換の成功を示しません。chronyc sources、journal、組織のDNS診断とファイアウォールログを使います。プロキシは通常のNTP UDP通信を中継しないため、ネットワーク管理者へ許可経路を確認します。
設定ファイルにサーバーがあるのに選ばれない
誤ったファイルを編集していないか確認します。RHELの/etc/chrony.confとUbuntuの/etc/chrony/chrony.confを混同しないでください。Ubuntuでは/etc/chrony/sources.d/やDHCP由来のソースもあります。sourcesでxや~になっている場合は、他ソースとの不一致、過大な変動、ルート距離など品質条件を調べます。値を大幅に緩めて強制選択する前に、時刻ソース側を修正します。
ログファイルが見つからない
/var/log/ntp.logや/var/log/chrony/chrony.logが必ず存在するとは限りません。systemd環境ではjournalを確認します。利用中のサービス名だけを選んでください。
journalctl -u chronyd --since '-1 hour'
journalctl -u chrony.service --since '-1 hour'
journalctl -u systemd-timesyncd --since '-1 hour'管理権限に関する注記：sudo chronyc -N authdataは通常、rootまたはchronyユーザーだけが利用できるローカルUnixソケットへのアクセスを必要とします。ディストリビューションで明示的に許可されたローカルアクセスを使う場合を除き、501 Not authorisedなどの権限エラーはNTS通信失敗と判定せず、先に実行権限を確認してください。journalctlの全文閲覧も、ディストリビューションの設定によりsudo、またはsystemd-journal/adm相当グループへの所属が必要な場合があります。
NTSを使う場合の確認
Network Time SecurityはTLSで鍵を確立し、その鍵でNTPパケットを認証します。chronyはNTSをサポートし、Ubuntu 25.10以降の既定chrony構成ではUbuntuのNTSプールを使います。NTS鍵交換にはTCP 4460、時刻同期にはUDP 123を使うため、UDP 123だけ許可しても同期できません。
組織が指定するNTS対応サーバーを使う設定例は次の形です。example.netを実在確認せず設定せず、管理者が証明書、名前、許可経路を確認します。
server time.example.net iburst nts鍵確立の状態は次で確認できます。KeyID、Type、KLenが0の場合は認証が確立していないため、journalの証明書エラー、TCP 4460、初期時刻を確認します。
sudo chronyc -N authdataTLS証明書の検証にはおおむね妥当な初期時刻が必要です。時計が大幅にずれた端末ではNTS接続自体が失敗することがあります。証明書時刻検証を恒久的に無効化するのではなく、ディストリビューションが提供するブートストラップ設計や組織内の信頼済み時刻源を使います。
ファイアウォールはクライアントとサーバーを分ける
| 役割 | 必要な通信の考え方 | 避ける設定 |
|---|---|---|
| NTPクライアント | 許可された時刻源へのUDP 123送信と戻り通信。NTSならTCP 4460送信も必要 | インターネット全体からUDP 123着信を許可 |
| 組織内NTPサーバー | 許可した内部サブネットからのUDP 123を受信 | 送信元を限定せず公開 |
| NTSサーバー | NTPに加えNTS-KEのTCP 4460を設計 | 証明書検証を無効化して接続だけ通す |
クライアントとして時刻を取得するだけなら、通常はインターネットからのUDP 123着信を広く開ける必要はありません。NTPサーバーとして提供する場合も、chronyのallow設定とネットワークファイアウォールの両方で許可する内部ネットワークを限定します。公開NTPサービスを運用する場合は、増幅攻撃、レート制限、監視を含む別設計が必要です。
時刻を強制的に飛ばす前の注意
chronyc makestepは時計を即時に補正できますが、データベースのトランザクション、Kerberos、証明書、分散ジョブ、ログの順序、監視に影響します。通常の確認手順として実行しません。大きなずれを直す必要がある場合は、影響するアプリケーションを停止し、保守時間と復旧計画を設け、組織の手順に従います。
仮想マシンでは、ハイパーバイザーのゲスト時刻同期とOS側デーモンが互いに補正し合うことがあります。クラウドや仮想化基盤の公式設計に従い、どちらを基準にするかを決めます。時計が周期的に前後する場合は、NTPサーバーだけでなくゲストツールとホスト側設定も確認します。
監視に使う判定項目
- 同期済みか、未同期か。chronyではLeap statusと選択ソースを確認します。
- 最後に正常な測定を得た時刻と、連続して応答しているか。
- System time、Last offset、RMS offset、Root dispersionがサービス要件内か。
- ソースが一つに偏り、比較対象が失われていないか。
- NTSを使う場合、authdataの鍵確立と証明書エラーがないか。
- 時刻ジャンプ、ソース切り替え、到達性低下をjournalで追跡できるか。
監視しきい値は、単一の公開値ではなく、認証、ログ相関、決済、データベース、分散処理などシステム要件から決めます。到達しているだけでなく、正しいソースを選び、誤差が許容範囲にあることを監視してください。
よくある質問
timedatectlでNTP service activeなら正常ですか
十分ではありません。サービスが有効でもソース未選択や大きな誤差があり得ます。chronyならtrackingとsources、timesyncdならjournalを確認します。
chronydとchronyは別製品ですか
同じchronyスイートです。デーモン実行ファイルはchronyd、操作コマンドはchronycです。systemdユニット名はRHELでchronyd、Ubuntuでchronyとなる代表的な違いがあります。
ntpq -pが見つかりません
chrony環境なら正常です。ntpqを追加するのではなくchronycを使います。どのデーモンがactiveかを先に確認してください。
Reachが377なら必ず同期していますか
必ずではありません。応答履歴が良好でも、品質判定で選択されていない場合があります。行頭記号、Last sample、trackingのLeap statusを合わせて見ます。
UDP 123を開ければ直りますか
役割によります。クライアントは許可された宛先への通信と戻り通信を確認します。NTSならTCP 4460も必要です。インターネットからのUDP 123着信を広く許可しないでください。
pool.ntp.orgを4行書けば安全ですか
組織の要件とディストリビューション既定を確認せず置き換えないでください。社内の信頼済みソース、クラウドの時刻サービス、NTS対応、DHCP配布など既存設計がある場合があります。
公式情報
- Ubuntu Server：Synchronize time using chrony
- Ubuntu Server：Synchronize time using timedatectl and timesyncd
- Red Hat：Configuring time synchronization
- chrony project：chronyc manual
- chrony project：Frequently Asked Questions
- RFC Editor：RFC 5905 Network Time Protocol Version 4
まとめ
LinuxのNTP確認は、稼働デーモンの特定から始めます。chronyはtracking、sources、sourcestats、systemd-timesyncdはtimedatectlとjournal、ntpd/NTPsecはntpqを使います。UbuntuとRHELではサービス名と設定場所が異なり、クライアントへUDP 123着信を広く開ける必要はありません。NTSではTCP 4460とUDP 123、証明書、authdataを確認し、時刻の強制ジャンプや複数デーモンの同時稼働を避けてください。
コメント