--- title: "chronyとは：chrony.confの設定とchronyc sources・trackingの読み方【4.9系】" url: "https://www.issoh.co.jp/tech/details/17855/" published: 2026-09-26 updated: 2026-10-27 categories: ["OS"] publisher: "株式会社一創" --- # chronyとは：chrony.confの設定とchronyc sources・trackingの読み方【4.9系】 chronyは、LinuxなどのUnix系OSで時刻をNTPサーバーに合わせるオープンソースのソフトウェアです。常駐するデーモンのchronydと、状態を確かめる操作用コマンドのchronycで構成され、最新版は2026年8月27日に[公開された4.9](https://chrony-project.org/news.html)です。RHEL系やAmazon Linux 2023では標準の時刻同期デーモンで、Ubuntuも25.10から既定をchronyへ切り替えました。 この記事では、`chrony.conf`の主要な行の意味と、`chronyc sources`・`chronyc tracking`・`chronyc clients`の出力を全項目で読み解きます。出力例は、主に2026年10月27日にUbuntu 26.04.1 LTSとAlmaLinux 10.2のコンテナで取得した値です。trackingの通常表示には公式マニュアルの例を使っています。後半ではAWS EC2の設定、NTSとうるう秒で詰まる箇所、エラーの切り分けを扱います。 ## まとめ：chronyの同期先・確認コマンド・出力の見どころ 同期先は、クラウド上ならそのクラウドのリンクローカルな時刻源にします。オンプレミスなら社内NTPサーバーや国内の公開NTPを、狂った1台を多数決で外せるよう3〜4台指定します。起動直後の大きなずれだけを`makestep`で一気に直し、監視では`chronyc tracking`のSystem time・Leap status・誤差の上限を見て、同期外れと精度要件からの逸脱を検知します。 - **構成**：chronydが時刻を合わせ、chronycが状態を表示する。設定ファイルはRHEL系が`/etc/chrony.conf`、Ubuntu系が`/etc/chrony/chrony.conf` - **sourcesの読み方**：`^*`の行が同期中の時刻源。Reachが377なら直近8回とも応答あり。Last sampleの`+/-`の右が誤差の幅 - **trackingの読み方**：System timeが残っている補正量、Leap statusが`Not synchronised`なら同期外れ。誤差の上限は|System time|＋Root dispersion＋（Root delay÷2） - **clientsの読み方**：NTPの問い合わせ元とコマンドのアクセス元を数える。rootかchronyユーザーで実行しないと`501 Not authorised`になる - **AWS EC2**：`169.254.169.123`を`prefer`で1行追加する。Ubuntu 25.10以降はNTSの既定プールを先に無効にする - **詰まる箇所**：Ubuntu 25.10以降の既定はNTSで4460/tcpを使う。うるう秒をスミアする時刻源とスミアしない時刻源を混ぜない ## chronyとはchronydとchronycで構成されるLinuxのNTP実装 サーバーの時計は、水晶発振子の個体差や温度で少しずつずれていきます。NTP（Network Time Protocol）は、正確な時刻を持つサーバーへネットワーク越しに問い合わせ、その差を打ち消す仕組みです。chronyはこのNTPの実装で、[GitLabで開発](https://gitlab.com/chrony/chrony)され、GNU GPL v2で配布されています。 chronydは常駐して時計を補正し、chronycは同期先の一覧やずれの表示、設定の再読み込みを行います。常駐の仕組みは[Linuxの仕組みとサーバー用途を扱った解説](/tech/details/13160/)とあわせて読むと位置づけがつかめます。 ### ntpdやsystemd-timesyncdとの違いと主要ディストリの既定 chronyの前はNTPの参照実装ntpdが長く使われてきました。[公式FAQ](https://chrony-project.org/faq.html)は、chronyを「より幅広い条件で動くよう設計され、通常はより速く同期し精度も高い」と説明しています。 systemd-timesyncdは[systemd](/tech/details/8160/)に同梱された軽量なクライアントで、時刻を受け取れますが他のマシンへ配ることはできません。 | 項目 | chrony | ntpd | systemd-timesyncd | | ---------- | --------------------------- | ----- | ----------------- | | 時刻の配信 | できる | できる | できない | | NTS（暗号化認証） | 対応 | 非対応 | 非対応 | | 主な採用先 | RHEL系・AL2023・Ubuntu 25.10以降 | 旧来の環境 | Ubuntu 25.04以前など | 2026年10月27日に確かめた配布パッケージは、上流の4.9に対して4.8系でした（Ubuntu 26.04.1 LTSは`4.8-2ubuntu1`、AlmaLinux 10.2は`chrony-4.8-2.el10`）。この記事で扱うコマンドと出力の形式は4.8と4.9で変わりません。 ### 4.9と4.8で加わった機能とNTSの位置づけ 4.9ではOpenBSDへの対応と、NTPをPTPの上で運ぶ機能をRFC 10030の最終仕様に合わせる変更が入りました。4.8（2025年8月27日公開）では、到達できない時刻源の選択を制限する`maxunreach`と、rootで起動したchronycの実行ユーザーを切り替えて権限を落とす`-u user`が加わっています。 業務サーバーで押さえるべき機能はNTSです。[RFC 8915](https://www.rfc-editor.org/info/rfc8915/)で規格化されたNetwork Time Securityの略で、NTPの応答が本物のサーバーから来たことを暗号で確かめられます。公開NTPを使う構成では、応答の認証が必要ならNTS対応の時刻源を選びます。 ## chrony.confでNTPサーバーを指定しchronydを起動する手順 導入はディストリビューションのパッケージで完結します。RHEL系やAmazon Linuxでは最初から入っていることが多く、Ubuntu 25.04以前ではaptで追加します。 ``` # RHEL系・Amazon Linux 2023 sudo dnf install -y chrony sudo systemctl enable --now chronyd # Ubuntu・Debian系（サービス名は chrony） sudo apt update sudo apt install -y chrony sudo systemctl enable --now chrony # 版と同期状態を確かめる chronyc -v chronyc tracking ``` サービス名はRHEL系が`chronyd`、Ubuntu系が`chrony`です。Ansibleなどで両系統を扱うなら変数に分けます。 ### Ubuntu既存環境のsystemd-timesyncdからchronyへの移行 Ubuntu 25.04以前から上げた環境では、timesyncdが動いたままの場合があります。[Ubuntu 26.04 LTSのリリースノート](https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/)は、chronyが既定になるのは新規インストールだけだとしたうえで、移行手順として次の2行を示しています。 ``` sudo apt-mark auto systemd-timesyncd sudo apt install chrony # 入れ替わったかを確かめる（timesyncd の行が rc になっていれば削除済み） dpkg -l | grep -E 'timesyncd|chrony' ``` 2つは同時に入りません。Ubuntu 26.04.1で試すと、両パッケージとも`Conflicts: time-daemon`を宣言しており、chronyを入れた時点でaptが「The following packages will be REMOVED: systemd-timesyncd」と表示して削除しました。手で止める作業は要りません。 ### RHEL系とUbuntu系で異なる設定ファイルの場所と再読み込み RHEL系とAmazon Linuxは`/etc/chrony.conf`の1ファイルです。AlmaLinux 10.2の既定は`pool 2.almalinux.pool.ntp.org iburst`と`makestep 1.0 3`で、起動オプションは`/etc/sysconfig/chronyd`の`OPTIONS="-F 2"`でした。 [Ubuntuの手順書](https://ubuntu.com/server/docs/how-to/networking/chrony-client/)によると、Ubuntu系は本体が`/etc/chrony/chrony.conf`で、同期先は`/etc/chrony/sources.d/`、追加設定は`/etc/chrony/conf.d/`に分けて置きます。sources.dのREADMEには、ファイル名は`.sources`で終えること、書けるのは`server`・`pool`・`peer`の行だけであることが書かれています。 同期先だけを差し替えるなら、sources.dにファイルを置いて`sudo chronyc reload sources`でデーモンを止めずに反映できます。`makestep`など本体の設定を変えたら`systemctl restart`が必要です。構成管理ツールで配るなら本体は触らず、sources.dとconf.dにファイルを足すとパッケージ更新時の衝突を避けられます。 ### pool・server・iburst・makestepの意味と書き換える行 実務で書き換えるのは、同期先の行と補正方式の行がほとんどです。次は社内NTPサーバー2台と公開NTPを組み合わせた例です。 ``` # /etc/chrony.conf（RHEL系の例） # 社内NTPサーバーを優先し、外部の公開NTPを予備にする server ntp1.example.internal iburst prefer server ntp2.example.internal iburst pool ntp.nict.jp iburst maxsources 2 # 起動直後の3回の更新に限り、1秒を超えるずれは即時に合わせる makestep 1 3 # 周波数のくせを保存し、再起動後の収束を早める driftfile /var/lib/chrony/drift # ハードウェアクロック（RTC）にも定期的に書き戻す rtcsync ``` `server`は1台のサーバーを、`pool`はDNSで複数のアドレスが返る名前を指定します。[chrony.confのリファレンス](https://chrony-project.org/doc/latest/chrony.conf.html)によると、poolから使うサーバー数を決める`maxsources`の既定は4、上限は16です。`iburst`を付けると起動時に4〜8回の問い合わせをまとめて送り、最初の補正が早まります。問い合わせ間隔の既定は最短64秒（`minpoll 6`）、最長1024秒（`maxpoll 10`）です。 `makestep`は補正方式を決める行です。chronydは通常、時計を少しずつ速めたり遅らせたりする「スルー」で合わせ、時刻を巻き戻しません。スルーの速さの上限（`maxslewrate`）は既定で83333.333ppm、つまり12分の1です。起動直後に数分ずれていると追いつくまで長くかかるため、公式FAQは`makestep 1 3`（最初の3回の更新で1秒を超えるずれがあれば時刻を飛ばす）を推奨しています。運用中に時刻が飛ぶとログの順序やタイマーが乱れるので、回数の制限は外さないでください。 ## chronyc sourcesの読み方：記号・Reach・Last sampleの各列 同期先ごとの状態は`chronyc sources`で見ます。`-v`を付けると列の凡例が上に出て、`-N`を付けると逆引きしたホスト名ではなく設定に書いた名前で表示されます。次はUbuntu 26.04.1の既定設定（NTSの5プール）で起動して約3分後の出力です。 ``` $ chronyc -N sources MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 1.ntp.ubuntu.com 2 6 77 20 +3825us[-3351us] +/- 123ms ^+ 2.ntp.ubuntu.com 2 6 77 20 +8186us[+8186us] +/- 126ms ^- 3.ntp.ubuntu.com 2 6 77 19 -18ms[ -18ms] +/- 187ms ^- 4.ntp.ubuntu.com 2 6 77 19 -6757us[-6757us] +/- 189ms ^- ntp-bootstrap.ubuntu.com 2 6 77 18 -700us[ -700us] +/- 115ms ``` コンテナ内では時計を操作できないため、chronydは時計を制御しない`-x`オプションで起動しています。同期先とのずれの測定はそのまま行われるので、sourcesの読み方の例として使えます。 ### MS列の2文字が示す接続方式と選択状態 1文字目が接続方式で、[chronycのマニュアル](https://chrony-project.org/doc/latest/chronyc.html)によると`^`はサーバー、`=`はピア、`#`はローカルの参照クロックです。2文字目が選択状態です。 - `*`：いま同期に使っている最良の時刻源。この行が1本も無ければ同期できていない - `+`：最良の時刻源と組み合わせて使われている時刻源 - `-`：候補としては有効だが、今は組み合わせに入っていない時刻源 - `?`：到達できない、同期していない、測定数が足りないなどで使えない時刻源 - `x`：他の多数派と時刻が食い違う「falseticker」と判定された時刻源 - `~`：ばらつきが大きすぎると判定された時刻源 同じUbuntuのコンテナで起動5秒後に取ると、5行とも`^?`でした。設定直後の`?`は測定数不足の場合もあるため、1〜2分待って再確認します。到達不能や時刻源側の未同期でも同じ記号になります。数分たっても`?`だけなら、ファイアウォールかNTSの鍵交換を疑います（後述）。 ### Stratum・Poll・Reach・LastRxの数値の意味 | 列 | 意味 | 上の例の読み方 | | ------- | ----------------------- | -------------------- | | Stratum | 時刻源の階層。原子時計などに直結した機器が1 | 2＝stratum 1から1段下 | | Poll | 問い合わせ間隔を2の何乗秒かで表した値 | 6＝64秒ごと | | Reach | 直近8回の応答の有無を8ビットで記録した8進数 | 77＝直近6回とも応答あり | | LastRx | 最後に良いサンプルを受け取ってからの経過 | 20＝20秒前。m・h・dは分・時間・日 | Reachは問い合わせのたびに1ビット左へずれ、応答があれば1が立ちます。8回とも応答があれば377です。起動直後は1、3、7、17、37、77、177と増え、今回のUbuntuでも起動5秒後は1と3、約3分後は77でした。377に達した後に途中の値を行き来するなら、パケットの取りこぼしを疑って経路を調べます。 ### Last sampleの角括弧と+/-の読み方 Last sampleは3つの数で1組です。角括弧の中が実際に測ったずれ、左がその後のスルー補正の分を差し引いたずれ、`+/-`の右が測定の誤差の幅（NTPのroot distance）です。**正の値は自分の時計が時刻源より進んでいる**ことを表します。単位はns・us・ms・sが付きます。 上の`^*`行の`+3825us[-3351us] +/- 123ms`は、測定時点では3.4ミリ秒遅れていた値が、その後の補正込みでは3.8ミリ秒進んでいる、誤差の幅は±123ミリ秒、という意味です。この誤差幅には往復遅延と上流までに積み上がる誤差が含まれます。同じ測定環境で、AlmaLinuxから`ntp.nict.jp`（NICTのstratum 1）を指定すると`+/- 15ms`でした。今回の測定では、Ubuntuの既定プールの誤差幅はNICTを指定した場合より約8〜13倍大きくなりました。この差は接続元や経路、測定時点で変わります。国内の公開NTPか社内NTPサーバーを足すかは、この幅を見て決めてください。 ### sourcestatsによる時刻源ごとのばらつきの比較 どの時刻源が安定しているかは`chronyc sourcestats`で比べます。同じUbuntuの出力です。 ``` $ chronyc sourcestats Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 185.125.190.122 6 4 136 +44.693 341.900 +6879us 4523us 185.125.190.121 6 5 137 +0.790 133.198 -454us 2204us 91.189.91.112 6 4 136 +175.749 1185.883 -11ms 14ms ``` NPは保持しているサンプル数、NRは回帰直線に対する残差の符号が続いた回数、Spanは最古と最新のサンプルの間隔（単位が無ければ秒）です。Frequencyはその時刻源に対する周波数のずれ、Freq Skewはその推定誤差（いずれもppm）、Offsetは推定したずれ、Std Devはサンプルの標準偏差です。起動直後はNPが少なくFreq Skewが大きいため、比べるのは数十分たってからにします。Std Devが他より大きい時刻源は、十分な測定期間を取ったうえでReachや選択状態も確認し、必要な時刻源数を維持できる場合に除外を検討します。 ## chronyc trackingの読み方：全13項目と監視の閾値 `chronyc tracking`は、時刻源ではなく自分の時計の状態を表示します。項目の並びは次のとおりで、値はchronycのマニュアルに載っている例です。 ``` $ chronyc tracking Reference ID : CB00710F (ntp1.example.net) Stratum : 3 Ref time (UTC) : Fri Jan 27 09:49:17 2017 System time : 0.000006523 seconds slow of NTP time Last offset : -0.000006747 seconds RMS offset : 0.000035822 seconds Frequency : 3.225 ppm slow Residual freq : -0.000 ppm Skew : 0.129 ppm Root delay : 0.013639022 seconds Root dispersion : 0.001100737 seconds Update interval : 64.2 seconds Leap status : Normal ``` ### trackingの13項目の意味と監視での確認箇所 | 項目 | 意味 | 見る観点 | | --------------- | -------------------- | ---------------------- | | Reference ID | 同期先のIDと名前 | 7F7F0101なら外部と同期していない | | Stratum | 自分の階層 | 同期先のStratumに1を足した値 | | Ref time (UTC) | 同期先の最後の測定を処理した時刻 | 古いまま止まっていれば同期が途切れている | | System time | OSの時計に残っている補正量 | 監視の主指標。slowは遅れ、fastは進み | | Last offset | 直前の更新で推定したずれ | 正なら自分の時計が進んでいた | | RMS offset | ずれの長期平均 | 精度の実力値 | | Frequency | 補正しなかった場合の時計の狂いの速さ | 1ppmで1日約86ミリ秒 | | Residual freq | 測定が示す周波数と使用中の値の差 | 傾向が一定なら0に近づく | | Skew | 周波数の推定誤差 | 大きいうちは同期の途中 | | Root delay | stratum 1までの経路遅延の合計 | 誤差上限の計算に使う | | Root dispersion | stratum 1までに積み上がった誤差 | 誤差上限の計算に使う | | Update interval | 直近2回の時計更新の間隔 | Pollとおおむね一致する | | Leap status | うるう秒と同期の状態 | Not synchronisedなら同期外れ | System timeが減り続けている場合は、スルー補正の途中と考えられます。減らない場合は、同期状態や時計制御を無効にする-xの指定も確認してください。なお、chronycが表示するSystem time以外のずれは、OSの時計ではなくchronydが内部に持つ時計に対する値です。 ### 時計の誤差の上限を計算する式 trackingの値から、時計が正しい時刻から最大でどれだけずれうるかを計算できます。マニュアルにある式は次のとおりです（stratum 1が正しいと仮定）。 ``` 誤差の上限 <= |System time| + Root dispersion + (0.5 × Root delay) 上の例：0.000006523 + 0.001100737 + 0.5 × 0.013639022 = 0.007926771 秒（約7.9ミリ秒） ``` System timeが0.0065ミリ秒でも、保証できる精度は約7.9ミリ秒です。ミリ秒単位の順序を要件に持つシステムでは、System timeではなくこの上限で判定してください。 ### 監視の閾値の決め方とCSV出力での判定 閾値はシステムの要件から逆算します。ワンタイムパスワード（TOTP）はRFC 6238の推奨値である30秒刻みでコードが変わり（[HOTPとTOTPの生成アルゴリズムを扱った記事](/tech/details/13455/)）、Kerberos認証は既定で5分を超える時刻差を拒否します。一般的なWebシステムなら0.1秒、分散データベースやログの突き合わせを厳密に行うシステムならミリ秒単位を目安にします。 監視スクリプトでは`-c`オプションでCSVにします。単位の変換と逆引きが無くなり、秒の値がそのまま出ます。5列目がSystem time、最後の14列目がLeap statusです。次の1行は、ずれが0.1秒を超えるか、Leap statusが`Not synchronised`になるか、chronycが失敗して値が取れなければ終了コード1を返します。うるう秒の予告（`Insert second`・`Delete second`）は同期中なので正常とみなします。下のCSVを入力にして、正常・ずれ0.2秒・うるう秒予告・同期外れ・空の出力・chronycの失敗の6通りで、終了コードが0、1、0、1、1、1になることを確かめています。 ``` $ chronyc -c tracking 5BBD5B70,91.189.91.112,3,1793027877.460782338,-0.009958650,0.009958650,0.009958650,0.000,1309.736,1000000.000,0.357606858,1.647891641,0.0,Normal # 監視用（終了コード 0=正常 / 1=要対応） data=$(chronyc -c tracking) && printf '%s\n' "$data" | awk -F, 'NF!=14 {exit 1} {o=$5; if (o<0) o=-o; if (o>0.1 || $14 !~ /^(Normal|Insert second|Delete second)$/) {print "NG offset="$5" leap="$14; exit 1} print "OK offset="$5}' ``` 上のCSVは時計を制御しない`-x`で取った値のため、FrequencyとSkewは参考になりません。監視項目の分担は[外形監視と内部監視の違いを整理した記事](/tech/details/15223/)で扱っています。 ## chronyc clientsとauthdataによるアクセス元とNTS認証状態の確認 chronyを社内NTPサーバーにした場合、どのマシンが問い合わせてきているかは`chronyc clients`で見ます。[chrony.confのリファレンス](https://chrony-project.org/doc/latest/chrony.conf.html)のとおり、既定ではNTPクライアントを1台も許可しないため、`allow`を書いていないサーバーには問い合わせ元が載りません。載るのは`cmdallow`などで許可されたネットワーク経由のコマンドのアクセスだけで、今回のUbuntuの既定設定では空でした。 ### chronyc clientsの列の読み方 AlmaLinux 10.2で`allow 127.0.0.0/8`を書き、同じマシンから3回問い合わせた後の出力です。 ``` $ sudo chronyc clients Hostname NTP Drop Int IntL Last Cmd Drop Int Last =============================================================================== localhost 9 0 1 - 0 0 0 - - ``` | 列 | 意味 | | -------------------- | ------------------------- | | NTP | そのクライアントから受け取ったNTPパケット数 | | Drop（左） | 応答レートの制限で捨てたNTPパケット数 | | Int | NTPパケットの平均間隔（2の何乗秒か） | | IntL | レート制限をかけた後の平均間隔 | | Last | 最後のNTPパケットからの経過時間 | | Cmd・Drop・Int・Last（右） | chronycのコマンドかNTS-KE接続の同じ値 | Intが1なので平均約2秒間隔、Dropが0なので応答レート制限による破棄は記録されていません。右側の4列は既定ではコマンドの集計で、`-k`を付けるとNTSの鍵交換（NTS-KE）の集計に切り替わります。ローカルのUnixドメインソケット経由の操作は数えません。全体の合計は`chronyc serverstats`で見られ、今回は「NTP packets received : 9」でした。 ### authdataとntpdataによるNTS認証状態の確認 NTSで同期できているかは`chronyc -N authdata`のMode列で確かめます。Ubuntu 26.04.1の既定設定では、5つの時刻源がすべて`NTS`でした。 ``` $ sudo chronyc -N authdata Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen ========================================================================= 1.ntp.ubuntu.com NTS 1 30 128 156 0 0 8 64 2.ntp.ubuntu.com NTS 1 30 128 156 0 0 8 64 $ sudo chronyc -n ntpdata 185.125.190.122 | grep -E 'Authenticated|Peer delay' Peer delay : 0.243015617 seconds Authenticated : Yes ``` Modeが`-`なら認証なし、`SK`なら共通鍵での認証です。Typeの30は暗号方式AEAD-AES-128-GCM-SIV、Lastは最後に鍵交換が成功してからの経過秒数です。Atmpは前回の成功以降の鍵交換の試行回数で、マニュアルは1より大きければネットワークかサーバーに問題があるとしています。`ntpdata`は時刻源ごとの生の値を出し、`Authenticated : Yes`なら応答が認証済みです。この時刻源のPeer delay（往復の遅延）は約0.24秒で、前の章で見た誤差幅±123ミリ秒の原因はここにあります。 ## chronycのエラー（506 Cannot talk to daemon・501 Not authorised）の切り分け chronycが値を返さずエラーになる原因は、2つの番号でほぼ分かれます。[公式FAQ](https://chrony-project.org/faq.html)の説明に沿って整理します。 - **506 Cannot talk to daemon**：chronydに届いていない。まず`systemctl status chronyd`（Ubuntuは`chrony`）で起動しているかを見る。起動していればUDP 323番がファイアウォールで塞がれていないかを確かめる。別のマシンから操作するなら、chronyd側に`cmdallow`と`bindcmdaddress`が要る - **501 Not authorised**：届いたが権限が無い。chronycはまずUnixドメインソケットに接続し、使えなければ127.0.0.1のUDPへ切り替える。ソケットに入れるのはrootとchronyユーザーだけで、UDP経由では`sources`・`tracking`・`waitsync`など一部の表示系しか受け付けない Ubuntu 26.04.1で一般ユーザー（nobody）として実行すると、`chronyc tracking`は表示でき、`chronyc clients`は「501 Not authorised」になりました。監視エージェントを一般ユーザーで動かすなら、trackingとsourcesだけを使う設計にしておくとsudoの設定が要りません。 ## AWS EC2でAmazon Time Sync Serviceへ同期させる設定 EC2では、インターネット上の公開NTPではなく、AWSが各インスタンスに用意している時刻源へ向けるのが基本です。[EC2ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html)によると、Amazon Time Sync ServiceにはリンクローカルアドレスのIPv4 `169.254.169.123`で届き、VPCの設定を変えずに使えます。IPv6の`fd00:ec2::123`はNitroベースのインスタンスでのみ使えます。 ### 169.254.169.123をpreferで指定する1行とIPv6の扱い AL2023と最近のAmazon Linux 2は、最初からこの時刻源を使う設定です。UbuntuやRHELのAMIでは、既存の`server`や`pool`の行より前に次の1行を足します。Ubuntu 25.10以降は、先に次の見出しの手順でNTSの既定プールを無効にしてください。既定の`authselectmode mix`では、NTSで認証された時刻源に`require`と`trust`が付き、[リファレンス](https://chrony-project.org/doc/latest/chrony.conf.html)のとおり`require`付きの時刻源が1つも使えないと時計は更新されません。NTSの鍵交換が通らないサブネットでは、Amazon Time Syncの行を足しても同期しないことになります。 ``` # Ubuntu系は /etc/chrony/sources.d/aws.sources に置くと reload で反映できる server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4 # 反映して確認する（^* が 169.254.169.123 なら完了） sudo chronyc reload sources # RHEL系は sudo systemctl restart chronyd chronyc -n sources | grep -F '^*' ``` `minpoll 4 maxpoll 4`は16秒ごとに問い合わせる指定です。ガイドには、リンクローカルアドレス宛ての通信はDNSの問い合わせやインスタンスメタデータの取得と合算して毎秒1024パケットまでという制限があります。IPv4とIPv6の両方を書いても精度は上がらないと明記されているため、どちらか一方にします。 ### Ubuntu 25.10以降のNTS既定が閉じたサブネットで失敗する理由 Ubuntu 25.10以降を新規に入れると、同期先は`sources.d/ubuntu-ntp-pools.sources`に次のように書かれています（Ubuntu 26.04.1で確認）。 ``` pool 1.ntp.ubuntu.com iburst maxsources 1 nts prefer pool 2.ntp.ubuntu.com iburst maxsources 1 nts prefer pool 3.ntp.ubuntu.com iburst maxsources 1 nts prefer pool 4.ntp.ubuntu.com iburst maxsources 1 nts prefer pool ntp-bootstrap.ubuntu.com iburst maxsources 1 nts certset 1 ``` `nts`が付いた時刻源は、時刻の問い合わせ（123/udp）の前に鍵交換を4460/tcpで行います。Ubuntuの手順書は、このポートが塞がれているとchronyが時刻を合わせられないと注意しています。NATゲートウェイを持たないプライベートサブネットや、外向き通信を許可リストで絞ったセキュリティグループでは鍵交換が通らず、`chronyc sources`が`^?`だけになります。 EC2ではNTSの外部プールを使う理由がほぼありません。前の見出しの1行をsources.dに置き、`ubuntu-ntp-pools.sources`の行はコメントアウトしてください。リンクローカルの時刻源はVPCの外へ出ないため、偽装の心配も遠いプールの往復遅延も避けられます。 ## 社内NTPサーバー化とうるう秒スミアの混在で詰まる箇所 chronyはそのまま社内向けのNTPサーバーになれます。外部へ問い合わせるのを社内NTPサーバーに限り、残りはそこへ同期させる構成がよく取られます。 ### allowで配信を許可するときのfirewall設定と4460番ポート 配信側では`allow`で受け付けるネットワークを指定します。公式FAQのとおり、サブネットを書かない`allow`はIPv4とIPv6のすべてのアドレスを許可してしまうため、必ず範囲を付けます。 ``` # /etc/chrony.conf（社内NTPサーバー側） pool ntp.nict.jp iburst maxsources 4 allow 10.0.0.0/16 makestep 1 3 driftfile /var/lib/chrony/drift rtcsync # firewalld で 123/udp を開ける sudo firewall-cmd --permanent --add-service=ntp sudo firewall-cmd --reload # どのクライアントが問い合わせているかを確認する sudo chronyc clients ``` 社内NTPサーバーを1台にすると、その故障や時刻の狂いが全台へ波及します。公式FAQが通常3〜4台を勧めるとおり3台以上用意し、クライアント側では全台を`server`行に並べてください。3台あれば1台が狂っても多数決で`x`と判定して外せます。台数と停止許容時間の考え方は[稼働率の計算と高可用性の設計を扱った記事](/tech/details/13423/)が参考になります。NTSで配信する場合は、ntsservercertとntsserverkeyで証明書と秘密鍵を設定し、123/udpに加えて4460/tcpも開けます。 ### うるう秒をスミアする時刻源としない時刻源を同期先に混ぜない設計 うるう秒が挿入される日には、時刻源によって扱いが分かれます。EC2ユーザーガイドは、Amazon Time SyncのNTPの時刻源はうるう秒を「スミア」した時刻を返し、PTPハードウェアクロック（PHC）はスミアしないと明記しています。スミアとは、1秒を一気に挿入せず、前後の長い時間に薄く分散させて吸収する方式です。 この2種類を同じchronyの同期先に並べると、うるう秒の前後で時刻源どうしが最大1秒食い違い、chronydが一部を`x`と判定して外したり、選ばれる時刻源が切り替わったりします。AWSのガイドも、うるう秒の発生時に両者を混ぜないよう求めています。AWS上ではAmazon Time Syncだけに寄せ、オンプレミスと混在するなら社内NTPサーバー側で扱いを揃えてから配ってください。自前でスミアしたい場合、リファレンスには`leapsecmode slew`、`maxslewrate 1000`、`smoothtime 400 0.001024 leaponly`を組み合わせる例が載っています。 ## 受託開発のサーバー構築でchronyの設定を標準化する条件と見送る場面 chronyはどのディストリビューションでも既定の設定で動き始めるため、全案件で手を入れる必要はありません。次のどれかに当てはまるシステムでは、同期先と監視を構築手順に明記して標準化します。 - **時刻のずれが認証失敗になる**：TOTP、Kerberos、署名付きURLやJWTの有効期限を使う - **複数台の記録を時刻で突き合わせる**：分散データベース、監査ログ、決済や受発注の順序を後から検証する - **外向き通信を絞ったネットワークに置く**：プライベートサブネットのEC2、閉域網のオンプレミス。既定の同期先に届かない - **既定のUbuntuプールで要件を満たさない**：今回の測定では誤差幅が±115〜189ミリ秒でしたが、実際の値は環境ごとに確認します。ミリ秒単位の要件があれば国内の時刻源を足す 逆に、小規模なWebサーバーや検証環境で、AL2023のように最初からクラウドの時刻源を向いている場合は既定のままで十分です。`chronyc sources`で`^*`を確かめる1行を構築後チェックに入れるだけにし、独自設定は足さないでください。足すほどOS更新時に差分を見直す手間が増えます。 判断が難しいのは、EC2とオンプレミス、別のクラウドが混在する構成です。スミアの違いやNTSの鍵交換の通り道がネットワーク設計と絡むため、時刻の基準と配る経路は、サーバーを置く場所と一緒に決めると手戻りが少なく済みます。社内で設計の手が足りない場合は、一創の[インフラ構築（AWS・Google Cloud・Azure）](/service/system/aws/)で、ネットワークと時刻同期を含めた基盤の設計から相談できます。 ## よくある質問 ### chronyとntpdはどちらを使えばよいですか？ 新しく構築するならchronyです。RHEL系、Amazon Linux 2023、Ubuntu 25.10以降の既定で、NTSにも対応します。ntpdから移す場合も`server`行の書式はほぼ同じなので、同期先の行はそのまま流用できます。 ### chronyで今すぐ時刻を合わせるコマンドはありますか？ `sudo chronyc makestep`を引数なしで実行すると、残っている補正をやめて時計をその場で飛ばします。本番環境ではまず`chronyc tracking`でずれの量を確かめ、1秒未満ならスルーでの収束を待つのが安全です。スクリプトで同期完了を待つなら`chronyc waitsync 60 0.01`のように書くと、10秒間隔で最大60回（約10分）、残りの補正が10ミリ秒未満になるまで待ちます。 ### chronyが使うポート番号は何番ですか？ NTPの問い合わせと配信は123/udp、NTSの鍵交換（NTS-KE）は4460/tcp、chronycからchronydへのネットワーク経由の操作は323/udpです。Ubuntu 25.10以降の既定設定はNTSのため、外向きの4460/tcpが塞がれた環境では同期に失敗します。chronycの操作は既定ではローカルからしか受け付けません。 ### timedatectlとchronycはどう使い分けますか？ `timedatectl`はタイムゾーンの設定や、同期が有効かどうかの確認に使うsystemdのコマンドです。「System clock synchronized: yes」で同期の有無は分かりますが、どの時刻源に何秒ずれているかは`chronyc sources`と`chronyc tracking`で調べます。 ### chrony.confを変更したあとは再起動が必要ですか？ 同期先の追加や削除だけなら、Ubuntu系ではsources.dに`.sources`で終わるファイルを置き、`sudo chronyc reload sources`を実行すればデーモンを止めずに反映できます（AlmaLinux 10.2でも`200 OK`が返りました）。`makestep`や`allow`など本体の設定を変えた場合は、RHEL系なら`sudo systemctl restart chronyd`、Ubuntu系なら`sudo systemctl restart chrony`で再起動してください。 ## 関連記事 - [Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点](/tech/details/2754/) - [Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約](/tech/details/6533/) - [Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り](/tech/details/17516/) - [冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】](/column/details/13356/) - [OpenSSHとは？最新バージョン10.6の確認方法とアップデート手順【2026年10月】](/tech/details/10191/) --- 出典: [chronyとは：chrony.confの設定とchronyc sources・trackingの読み方【4.9系】]()（株式会社一創）