NTP トラブル時に確認すること – chrony、ntpd、timesyncd の整理

この記事は、以前 NTP のトラブルに遭遇したときに調べた内容を、現在の Linux 運用で読みやすいように再整理したものです。

当時の記事は ntpd の ntpq -p を中心にまとめていましたが、現在は環境によって chrony、systemd-timesyncd、従来の ntpd が使い分けられます。そのため、まず「どの時刻同期サービスが動いているのか」を確認してから、同期先、到達性、オフセット、ジッターを見る方が実運用では分かりやすいです。

NTP とは何か

NTP は Network Time Protocol の略で、ネットワーク上の機器が持つ時計を基準時刻に同期するためのプロトコルです。サーバー、ネットワーク機器、仮想基盤、ログ基盤、認証基盤では、時刻のずれがトラブルの原因になります。

NTPv4 は RFC 5905 で仕様化されており、UTC を基準に時刻情報をやり取りします。単に時刻を受け取るだけではなく、通信遅延や複数の時刻源の信頼性を見ながら、ローカルクロックを少しずつ補正します。

最初に確認すること

NTP のトラブルでは、いきなり設定ファイルを見るより、まず現在の同期状態を確認します。Linux では次のように確認します。

timedatectl status

systemctl status chrony --no-pager
systemctl status systemd-timesyncd --no-pager
systemctl status ntp --no-pager

timedatectl は systemd 環境で時刻同期の大まかな状態を見るのに便利です。ただし、詳細な同期先やオフセットは、実際に使っている時刻同期サービス側のコマンドで確認します。

項目	見るところ
`chrony`	現在の Ubuntu などで使われることが多い。`chronyc` で詳細を確認する。
`systemd-timesyncd`	軽量な SNTP クライアント。サーバーとして時刻を配る用途には向かない。
`ntpd`	従来から使われてきた NTP デーモン。`ntpq -p` で状態を確認する。

stratum の意味

NTP には stratum と呼ばれる階層があります。GPS、標準電波、原子時計などの直接の時刻源は stratum 0 と考えられ、それに直結した NTP サーバーが stratum 1 になります。そこから下位へ参照関係が続くにつれて、stratum の値が大きくなります。

ただし、stratum の数字だけで良い NTP サーバーかどうかは判断できません。実際の精度には、ネットワーク遅延、経路の安定性、パケットロス、サーバーの負荷、複数の時刻源の整合性が関係します。遠い stratum 1 より、近くて安定した stratum 2 の方が扱いやすいこともあります。

chrony で確認する

chrony を使っている場合は、chronyc tracking と chronyc sources -v を確認します。Ubuntu では 25.10 以降、標準の時刻同期として chrony が使われるようになっています。

chronyc tracking
chronyc sources -v

tracking では、参照している時刻源、stratum、現在のずれ、周波数補正、root delay、root dispersion などを確認できます。sources -v では、どの時刻源が選択されているか、候補として残っているか、到達できているかを確認できます。

表示	意味
`^*`	現在同期に使われている時刻源。
`^+`	有効な候補として残っている時刻源。
`^-`	候補から外された時刻源。
`?`	到達できていない、または状態を判断できない時刻源。

NTP の確認では、単に System clock synchronized: yes だけを見るのではなく、どの時刻源に同期しているのか、オフセットが収束しているのか、複数の時刻源が極端に食い違っていないかを見ることが重要です。

ntpd で確認する

従来の ntpd を使っている場合は、ntpq -p で状態を確認します。古い Linux やアプライアンス、ネットワーク機器では、今でもこの見方が必要になることがあります。

ntpq -p

典型的な出力は次のようになります。

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.example.net  10.0.0.1       2 u  844 1024  377    0.828    0.226   0.108

Tally Code の見方

ntpq -p の先頭に付く記号は Tally Code と呼ばれ、NTP サーバーの選択状態を表します。

記号	意味
`*`	sys.peer。現在同期に使われている NTP サーバー。
`+`	candidate。同期候補として有効な NTP サーバー。
`#`	selected。同期距離などの理由で優先度は低いが参照可能な NTP サーバー。
`x`	falseticker。時刻源として不適切と判断された NTP サーバー。
`.`	excess。候補数が多いなどの理由で使われていない NTP サーバー。
`-`	outlier。クラスタリングの結果、外れ値として扱われた NTP サーバー。
空欄	reject。到達性や品質の問題で使われていない NTP サーバー。

正常に同期していれば、いずれかの時刻源に * が付きます。ただし、起動直後はすぐに * にならないことがあります。しばらく待っても同期しない場合は、到達性、設定、時刻差、ファイアウォールを確認します。

ntpq -p の主なフィールド

項目	見るところ
`remote`	参照している NTP サーバー。
`refid`	その NTP サーバーが参照している時刻源。GPS、上位 NTP サーバー、または識別子が表示される。
`st`	stratum 値。
`when`	最後に応答を受け取ってからの時間。
`poll`	問い合わせ間隔。同期が安定すると間隔は長くなる。
`reach`	直近 8 回分の到達性を 8 進数で表す。`377` は直近 8 回すべて成功を意味する。
`delay`	往復遅延の推定値。単位はミリ秒。
`offset`	ローカルクロックと時刻源のずれ。単位はミリ秒。
`jitter`	オフセットの揺らぎ。小さいほど安定している。

トラブル時に見るポイント

NTP の問題は、「同期していない」という結果だけを見ると原因が分かりにくいです。次の順番で切り分けると整理しやすくなります。

項目	見るところ
サービス	`chrony`、`systemd-timesyncd`、`ntpd` のどれが動いているか。複数が競合していないか。
到達性	UDP 123 番が通るか。外向き通信だけでなく、戻り通信が許可されているか。
名前解決	NTP サーバー名が DNS で解決できるか。起動直後に DNS が使えない環境では失敗しやすい。
時刻差	初期時刻が大きくずれていないか。TLS、証明書、NTS、認証系にも影響する。
時刻源	1 台だけに依存していないか。複数の時刻源が大きく食い違っていないか。
仮想環境	ホスト側の時刻、ゲスト OS の同期、VMware Tools や QEMU Guest Agent などの時刻補正が競合していないか。