「chronyc sourcesを打ったら、記号と数字が並んでいて、同期しているのか分かりません」
「仮想マシンの時刻が、ときどき1秒近く行ったり来たりします」
Linuxの時刻同期は、今やchronyが主流です。設定はシンプルですが、状態を表示するコマンドの出力には、読み方を知らないと分からない情報が詰まっています。
第3回では、NTPが時刻を測って直す仕組みを見ました。第4回では、その仕組みがchronyの設定と出力にどう現れるかを、Linuxのサーバーと仮想マシンを例に見ていきます。
ntpdからchronyへ
Linuxでは長くntpd（NTPの参照実装）が使われてきましたが、現在の主流はchronyです。
- Red Hat Enterprise Linux（RHEL）は7でchronyを既定にし、8以降はntpdを提供していない
- Ubuntuは18.04〜25.04で簡易なsystemd-timesyncdを既定にしていたが、25.10以降の新規インストールではchronyが既定になり、NTS（第8回）で時刻サーバーと同期する
- chronyは、常時つながっていない端末や仮想マシンのように時計が不安定な環境でも早く合わせられるよう設計されており、NTSやハードウェアタイムスタンプにも対応する。2026年9月時点の最新版は4.9（2026年8月）
ntpdの知識は、ネットワーク機器や古いサーバーの設定を読むときに役立ちます。
chronyの構成とファイルの場所
| 要素 | RHEL 系 | Ubuntu（25.10 以降） | 役割 |
|---|---|---|---|
| デーモン | chronyd（chronyd.service） | chronyd（chrony.service） | 時刻を測り、時計を直す本体 |
| 設定ファイル | /etc/chrony.conf | /etc/chrony/chrony.conf | 時刻源、直し方、配る範囲 |
| 追加の設定 | sourcedir /run/chrony-dhcp（DHCP で配られたサーバー） | /etc/chrony/sources.d/.sources、/etc/chrony/conf.d/.conf | 時刻源や設定を別ファイルで足す |
| ドリフトファイル | /var/lib/chrony/drift | /var/lib/chrony/chrony.drift | 時計の進み・遅れ（ppm）の記録 |
| 操作コマンド | chronyc | chronyc | 状態の確認と操作 |
| 通信 | UDP 123（NTP）、TCP 4460（NTS-KE） | 同左 | 時刻の問い合わせと NTS の鍵交換 |
chronycは同じホストのchronydとだけ通信し、変更を伴う操作（makestepなど）にはrootの権限が要ります。一般ユーザーで実行すると501 Not authorisedと返ります。chronyc -nで時刻源をIPアドレスで、-Nで設定に書いた名前で表示できます。Windowsの相当は、W32Timeサービスとw32tmです（第5回）。
chrony.confの主な設定
時刻源
| 設定 | 例 | 意味 |
|---|---|---|
| server | server ntp1.corp.example.jp iburst | 1台のサーバーを時刻源にする |
| pool | pool 2.rhel.pool.ntp.org iburst | 名前が返す複数のアドレスから時刻源を選ぶ |
| maxsources | pool … maxsources 4 | pool から使う台数。既定4、最大16 |
| iburst | server … iburst | 起動直後に4〜8回続けて問い合わせ、早く合わせる |
| minpoll／maxpoll | minpoll 6 maxpoll 10 | 問い合わせ間隔（2のべき乗秒）。既定は 6〜10（64〜1,024秒） |
| prefer | server … prefer | 条件が同じならこの時刻源を優先する |
| nts | server nts1.example.jp iburst nts | NTS で応答の正しさを確かめる（第8回） |
| minsources | minsources 2 | 使える時刻源がこの数に満たないと時計を直さない |
時刻源が1台だと、その1台が誤った時刻を返しても見抜けません。3〜4台を参照し、多数決で外れ値を除けるようにします（第3回）。社内のサーバーを並べるときはserver、DNSの名前で入れ替わる公開サービスにはpoolを使います。台数と参照先の設計は第7回で扱います。
時計の直し方・RTC・うるう秒
| 設定 | 例 | 意味 |
|---|---|---|
| makestep | makestep 1.0 3 | 最初の3回の更新までに1秒を超えてずれていれば、step で一気に合わせる。以降は slew だけ |
| maxslewrate | maxslewrate 500 | slew の速さの上限。chrony の既定は 83,333ppm（1/12）で、ntpd の 500ppm より速い |
| rtcsync | rtcsync | カーネルが11分ごとにシステム時刻を RTC に書き込む。コマンドではなく設定 |
| driftfile | driftfile /var/lib/chrony/drift | 時計の進み・遅れを1時間ごとに記録し、再起動の直後から補正に使う。chronyd が書き込める権限が必要 |
| leapsectz | leapsectz right/UTC | タイムゾーンのデータから、うるう秒の予定と TAI−UTC を知る |
| leapseclist | leapseclist /usr/share/zoneinfo/leap-seconds.list | 同じ目的で leap-seconds.list を読む（Ubuntu の既定） |
| leapsecmode | leapsecmode slew | うるう秒の直し方（system・step・slew・ignore）。既定は system（カーネルが1秒戻す） |
| smoothtime | smoothtime 400 0.001024 leaponly | サーバーとしてリープスメアを行う（配る時刻をゆっくりずらす） |
- RTCへ手動で書き込むコマンドは
hwclock -w（--systohc）で、rtcsyncを使えば不要 - リープスメアをするサーバーとしないサーバーを混ぜて参照してはいけない（第7回）。うるう秒は2027年5月20日から連続したUTCに移ることが決まったが（第2回）、それまでは設定を残す
サーバーとして時刻を配る
# 192.0.2.0/24 と 2001:db8:10::/64 のクライアントにだけ時刻を配る
allow 192.0.2.0/24
allow 2001:db8:10::/64
deny 192.0.2.128/28
# 上位と通信できない隔離環境でだけ使う（下の注意を参照）
local stratum 10 orphan
- 既定では
allowが無く、クライアントとしてだけ動く。allowを書いたときだけNTPサーバーになる（NTSの鍵交換の受け付けも同じ設定で決まる） - プレフィックス長を必ず書く：
allow 192.0.2.0/24。allow 192.0.2.0は1台のホストだけの許可になる。ドットの数で長さを決める省略形（allow 192.0.2は/24）もあるが、読み違えを防ぐためCIDRで書く local stratum 10は、上位を失っても「同期している」と名乗り続ける。隔離されたネットワーク専用。上位に届く環境で安易に使うと、ずれた時刻を正しい顔で配ってしまう。複数台に設定するときはorphanを付け、互いを参照させる- chronycの管理用の通信（UDP 323）は、既定で自ホストからだけ受け付ける
設定例：社内のNTPサーバーとクライアント
# ntp1.corp.example.jp（社内の NTP サーバー）の /etc/chrony.conf
# 外部の時刻源（選び方は第7回）
server ntp-a.example.jp iburst
server ntp-b.example.jp iburst
server ntp-c.example.jp iburst
server ntp-d.example.jp iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
leapsectz right/UTC
allow 192.0.2.0/24
logdir /var/log/chrony
# 一般のサーバー（クライアント）の /etc/chrony.conf
server ntp1.corp.example.jp iburst
server ntp2.corp.example.jp iburst
server ntp3.corp.example.jp iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync変更はsystemctl restart chronyd（Ubuntuはchrony）で反映し、Ubuntuのsources.dだけならchronyc reload sourcesで足ります。サーバー側はファイアウォールでUDP 123を開けます（RHELはfirewall-cmd --permanent --add-service=ntp）。Windowsで同じ役割を持たせる設定は第5回で扱います。
chronyc trackingの読み方
chronyc trackingは、自分の時計が今どれだけ正確かを表示します。
$ chronyc tracking
Reference ID : C000027B (ntp1.corp.example.jp)
Stratum : 3
Ref time (UTC) : Sat Sep 26 07:03:18 2026
System time : 0.000642552 seconds slow of NTP time
Last offset : -0.000104149 seconds
RMS offset : 0.000598395 seconds
Frequency : 2.581 ppm slow
Residual freq : +0.002 ppm
Skew : 0.151 ppm
Root delay : 0.002197427 seconds
Root dispersion : 0.000886113 seconds
Update interval : 64.2 seconds
Leap status : Normal| 項目 | 読み方 |
|---|---|
| Reference ID | 今の同期先。IPv4 ではアドレスの16進（C0.00.02.7B＝192.0.2.123）。7F7F0101 は local の設定で動作中 |
| Stratum | 同期先（stratum 2）の1つ下。上位を失うと値が上がる |
| Ref time (UTC) | 同期先の測定を最後に反映した時刻。古いままなら同期が止まっている |
| System time | 今のずれ。システム時計が chronyd の保つ時刻より 0.64ms 遅れており、slew で縮めている途中 |
| Last offset・RMS offset | 直前の更新で見積もったずれ（正なら自分が進んでいた）と、長期の平均。RMS は普段の精度の目安 |
| Frequency | 直さなければ時計がどれだけ遅れるか。2.581ppm は1日に約0.22秒 |
| Residual freq・Skew | 最新の測定と今の補正値の差、Frequency の見積もりの誤差。0 に近いほど安定 |
| Root delay・Root dispersion | stratum 1 までの往復の遅延の合計と、積み重なった誤差の見積もり（第3回） |
| Update interval | 直近2回の時計の更新の間隔 |
| Leap status | Normal、Insert second、Delete second、Not synchronised のいずれか。Not synchronised なら同期していない |
誤差の上限を見積もる
誤差の上限は「|System time| ＋ Root dispersion ＋ Root delay ÷ 2」で見積もれます（chronycの説明書）。この例では0.00064＋0.00089＋0.00110 ≒ 0.0026秒で、約2.6ms以内です。これを業務に必要な精度（第1回）と比べます。上限の多くは上位までの遅延と誤差なので、近い上位を選ぶと縮みます。Windowsではw32tm /query /status（第5回）で確かめます。
chronyc sourcesの読み方
冒頭の「記号と数字が並んでいて分からない」の答えです。
$ chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.corp.example.jp 2 6 377 34 +412us[ +398us] +/- 12ms
^+ ntp2.corp.example.jp 2 6 377 35 -803us[ -817us] +/- 15ms
^- ntp3.corp.example.jp 3 7 377 98 +3021us[+3021us] +/- 48ms
^x 198.51.100.20 2 6 377 40 +2102ms[+2102ms] +/- 20ms
^? 203.0.113.30 0 8 0 - +0ns[ +0ns] +/- 0ns| 記号 | 意味 |
|---|---|
| ^ = #（1文字目） | サーバー／ピア／直結の基準時計（GPS 受信機など） |
| * | 現在の同期先（最良と判断した時刻源） |
| + | 同期先と組み合わせて使っている時刻源 |
| – | 使える候補だが、今は組み合わせていない |
| ? | 使えない（届かない、同期していない、測定が足りない） |
| x | 誤り（falseticker）と判断：多数派と時刻が合わない |
| ~ | ばらつきが大きすぎる |
- Pollは問い合わせ間隔（2のべき乗秒、6なら64秒）、LastRxは最後に良い応答を受けてからの秒数
- Last sampleは「補正後のずれ[実測のずれ] +/- 誤差の範囲」。正のずれは自分が進んでいることを示す
- 上の例の
^x 198.51.100.20は、他より2秒も進んでいるため多数決で除かれた（第3回のfalseticker）。^?は一度も届いていない -vを付けると列の説明も表示される。Windowsの相当はw32tm /query /peers（第5回）
Reachの8進数とsourcestats
| Reach（8進数） | 2進数（右が最新） | 意味 |
|---|---|---|
| 377 | 11111111 | 直近8回すべて応答あり（正常） |
| 376 | 11111110 | 最新の1回だけ応答なし（一時的な欠落） |
| 177 | 01111111 | 8回前の1回だけ欠落。または起動後7回成功した途中 |
| 17 | 00001111 | 起動後4回成功した途中（iburst の直後によく見る） |
| 252 | 10101010 | 1回おきに欠落。回線の品質や相手のレート制限を疑う |
| 0 | 00000000 | 一度も届かない。名前解決、UDP 123、相手の停止を確認 |
$ chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
ntp1.corp.example.jp 12 7 12m +0.003 0.041 +405us 38us
ntp2.corp.example.jp 11 6 11m -0.012 0.066 -790us 52us
ntp3.corp.example.jp 8 5 15m +0.021 0.310 +2987us 410ussourcestatsは時刻源ごとの統計で、NPは保持している測定の数、Spanはその期間、Offsetはずれの見積もり、Std Devはばらつきです。Freq SkewやStd Devが他より大きい時刻源（上のntp3）は、経路が不安定か、時刻源自体の品質が低いと考えられます。
時刻を今すぐ合わせる
$ sudo chronyc makestep # 残っているずれを step で一気に解消
200 OK
$ sudo chronyc burst 4/4 # すぐに4回測り直す
200 OK
$ chronyc waitsync 30 0.01 # ずれが10ms未満になるまで待つ（10秒×最大30回）
try: 1, refid: C000027B, correction: 0.000576966, skew: 0.133
PS> w32tm /resync # Windows の相当（第5回）
chronyc makestepは時刻を飛ばす。データベース、ログの順序、タイマーなど、時刻の飛びに弱いアプリが動く本番では、停止中や保守の時間帯に行う- 起動時の自動のstepは
chrony.confのmakestep、手動のstepはchronyc makestep。rtcsyncはコマンドではなく設定で、手動のRTCへの書き込みはhwclock -w - 時刻が大きく未来にずれていた場合、stepで戻すと同じ時刻が2回現れる。ログの突き合わせやKerberosのチケットに影響するため、戻した時刻と幅を記録に残す
waitsyncは、起動スクリプトで「時刻が合うまで待ってからアプリを起動する」のに使える
systemd-timesyncdとtimedatectl
| 観点 | chrony | systemd-timesyncd |
|---|---|---|
| 種類 | NTP の完全な実装 | SNTP のクライアント（簡易版） |
| 時刻源の使い方 | 複数を同時に比べ、誤った時刻源を除く | 1台ずつ使う。誤った時刻を見抜けない |
| NTP サーバーになる | できる（allow） | できない |
| 設定 | chrony.conf | /etc/systemd/timesyncd.conf（NTP=、FallbackNTP=） |
| 状態の確認 | chronyc tracking、chronyc sources | timedatectl timesync-status |
| 向く用途 | サーバー、NTP サーバー、仮想マシン | 精度を求めない端末や最小構成 |
chronyとtimesyncdを同時に動かさないでください。別々に時計を直し、時刻が揺れます。Ubuntuではchronyを入れるとtimesyncdは削除されます（パッケージが競合）。timedatectlのNTP service: activeは、どちらかが動いていることを示します（timedatectlの表示は第2回）。WindowsではGet-TimeZone、w32tm /tzで確かめます。
仮想マシンの時刻
冒頭の「仮想マシンの時刻が行ったり来たりする」の原因は、多くの場合ここにあります。
- 仮想マシン（VM）の時計は、ホストのCPUを分け合って動くため、物理マシンより不安定。一時停止からの再開、スナップショットからの復元、ライブマイグレーション（vMotionなど）の後には、時刻が大きくずれることもある
- そこでハイパーバイザーは、ゲストの時刻をホストに合わせる機能を持っている。VMware ToolsやHyper-Vの統合サービスの時刻同期、KVMのkvm-clock（準仮想化クロック）とptp_kvmなど
- 問題は、ゲストのchronyとハイパーバイザーの機能が、別々の時刻源に向かって同時に時計を直す「二重の同期」。時刻が行ったり来たりし、ログの逆転や認証の失敗を招く
周期的に時計を合わせる仕組みは1つに決め、ゲストでchronyを使うなら、ハイパーバイザー側の周期的な同期は止めます。どちらでも、ホスト自身の時刻を正しく保つことが前提です（第6回）。
基盤ごとの設定とコンテナの時刻
| 基盤 | ハイパーバイザーの同期 | Linux ゲストの推奨 | 確認 |
|---|---|---|---|
| VMware vSphere | 周期的な同期は既定で無効。起動・再開・vMotion・スナップショット時の一回限りの同期は既定で有効 | chrony で社内 NTP と同期し、周期的な同期は無効のまま（第6回） | vmware-toolbox-cmd timesync status |
| Hyper-V | 統合サービスの時刻同期（既定で有効）。ホストの時刻を /dev/ptp_hyperv として提供 | chrony で refclock PHC /dev/ptp_hyperv を使う。NTP だけにするなら統合サービスの時刻同期を止める | ls /sys/class/ptp |
| KVM | kvm-clock。ptp_kvm でホストの時計を /dev/ptp_kvm として提供 | chrony で NTP、または refclock PHC /dev/ptp_kvm（ホストが正確な場合） | cat /sys/devices/system/clocksource/clocksource0/current_clocksource |
| クラウド | 各社の時刻サービス（Amazon Time Sync Service など） | イメージの既定の設定を使う（第7回、連載「クラウド入門」第7回） | chronyc sources |
コンテナは独自の時計を持たず、ホストのカーネルの時刻をそのまま使います。コンテナの中でchronyを動かす必要はなく、権限（CAP_SYS_TIME）が無いため通常は時刻を変えられません。Linuxの時間名前空間も単調時計などをずらすだけで、時刻は共有です。同期はホスト（Kubernetesならノード）で行い、タイムゾーンはコンテナごとにTZ環境変数などで指定します。
考えてみよう
- 自分が管理するLinuxサーバーで
chronyc sourcesを実行し、*と+の付いた時刻源が何台あるか確かめてください。1台しか無い場合、その1台が誤った時刻を返したら何が起きますか。 chronyc trackingのSystem time・Root delay・Root dispersionから、そのサーバーの時刻の誤差の上限を計算してみてください。業務に必要な精度（第1回）を満たしていますか。- VMwareやHyper-V上のLinuxのVMで、ハイパーバイザーの時刻同期とゲストのchronyが、それぞれどう設定されているか説明できますか。
ヒント：この記事の誤差の上限の式、sourcesの記号の表、二重の同期の図と基盤ごとの表が手がかりです。
まとめ
- RHEL・Ubuntuとも、既定の実装はchronyにそろった
- 時刻源は
serverで3〜4台。起動時だけmakestep 1.0 3、RTCはrtcsync - NTPサーバーにするなら
allowをCIDRで。localは隔離環境だけ trackingの|System time|＋Root dispersion＋Root delay÷2が誤差の上限sourcesの*が同期先、xは多数決で除かれた時刻源。Reach 377が正常makestepは時刻を飛ばす。本番では保守の時間帯に- 仮想マシンは二重の同期を避ける。コンテナはホストの時刻を共有する
次回は、Windowsの時刻同期（Windows Time サービス）と、ADドメインの時刻の階層を扱います。
連載「NTP入門」全11回
- なぜ時刻同期が必要か
- 時刻の基礎知識
- NTPの仕組み
- Linuxの時刻同期（chrony）（この記事）
- Windowsの時刻同期
- ネットワーク機器・仮想基盤
- 設計と推奨構成
- NTPのセキュリティ
- PTPと高精度同期
- 時刻同期のトラブルシュート
- 時刻同期の設計演習
コメント