chronyとは：chrony.confの設定とchronyc sources・trackingの読み方【4.9系】

chronyは、LinuxなどのUnix系OSで時刻をNTPサーバーに合わせるオープンソースのソフトウェアです。常駐するデーモンのchronydと、状態を確かめる操作用コマンドのchronycで構成され、最新版は2026年8月27日に公開された4.9です。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で開発され、GNU GPL v2で配布されています。

chronydは常駐して時計を補正し、chronycは同期先の一覧やずれの表示、設定の再読み込みを行います。常駐の仕組みはLinuxの仕組みとサーバー用途を扱った解説とあわせて読むと位置づけがつかめます。

ntpdやsystemd-timesyncdとの違いと主要ディストリの既定

chronyの前はNTPの参照実装ntpdが長く使われてきました。公式FAQは、chronyを「より幅広い条件で動くよう設計され、通常はより速く同期し精度も高い」と説明しています。

systemd-timesyncdはsystemdに同梱された軽量なクライアントで、時刻を受け取れますが他のマシンへ配ることはできません。

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で規格化された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のリリースノートは、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の手順書によると、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のリファレンスによると、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のマニュアルによると^はサーバー、=はピア、#はローカルの参照クロックです。2文字目が選択状態です。

• *：いま同期に使っている最良の時刻源。この行が1本も無ければ同期できていない
• +：最良の時刻源と組み合わせて使われている時刻源
• -：候補としては有効だが、今は組み合わせに入っていない時刻源
• ?：到達できない、同期していない、測定数が足りないなどで使えない時刻源
• x：他の多数派と時刻が食い違う「falseticker」と判定された時刻源
• ~：ばらつきが大きすぎると判定された時刻源

同じUbuntuのコンテナで起動5秒後に取ると、5行とも^?でした。設定直後の?は測定数不足の場合もあるため、1〜2分待って再確認します。到達不能や時刻源側の未同期でも同じ記号になります。数分たっても?だけなら、ファイアウォールかNTSの鍵交換を疑います（後述）。

Stratum・Poll・Reach・LastRxの数値の意味

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項目の意味と監視での確認箇所

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の生成アルゴリズムを扱った記事）、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は参考になりません。監視項目の分担は外形監視と内部監視の違いを整理した記事で扱っています。

chronyc clientsとauthdataによるアクセス元とNTS認証状態の確認

chronyを社内NTPサーバーにした場合、どのマシンが問い合わせてきているかはchronyc clientsで見ます。chrony.confのリファレンスのとおり、既定では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   -     -

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の説明に沿って整理します。

• 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ユーザーガイドによると、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が付き、リファレンスのとおり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と判定して外せます。台数と停止許容時間の考え方は稼働率の計算と高可用性の設計を扱った記事が参考になります。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）で、ネットワークと時刻同期を含めた基盤の設計から相談できます。

よくある質問

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での変更点
• Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約
• Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り
• 冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】
• OpenSSHとは？最新バージョン10.6の確認方法とアップデート手順【2026年10月】