Ubuntu 26.04 でサーバーを安定運用する場合、時刻同期は早い段階で確認しておきたい基本設定です。時刻がずれると、ログの前後関係、TLS 証明書、認証基盤、監査、Kubernetes など、さまざまな部分に影響します。
この記事では、Ubuntu 26.04 Server で chrony を使い、NTP による時刻同期を安定させる基本を整理します。systemd-timesyncd との違い、chrony.conf の設定、同期状態の確認、DNS / firewall / proxy 環境での切り分けまで扱います。
時刻同期は運用の前提である
時刻同期は、単に時計を合わせるだけの設定ではありません。複数サーバーのログを突き合わせる時、証明書の有効期限を検証する時、認証 token や Kerberos を扱う時、時刻のズレはそのまま障害要因になります。
| 領域 | 時刻ずれの影響 |
|---|---|
| ログ・監査 | 複数ホストの事象順序を追いにくくなる |
| TLS / 証明書 | 証明書の有効期限判定で問題が出る |
| 認証 | Kerberos、SAML、OIDC、MFA などで失敗要因になる |
| Kubernetes | 証明書、event、監視、分散処理の切り分けに影響する |
| バックアップ | 世代管理や差分判定が分かりにくくなる |
サーバーを作った直後に、IP アドレス、DNS、時刻同期を確認しておくと、その後の認証基盤や証明書、アプリケーション設定の切り分けが楽になります。
systemd-timesyncd と chrony を分けて考える
Ubuntu では systemd-timesyncd でも時刻同期できます。軽い検証環境であれば十分な場合もあります。一方で、サーバー群として内部 NTP を使う、同期状態を詳しく確認する、drift を管理する、起動直後の時刻補正を制御する場合は chrony の方が扱いやすくなります。
- 小規模な検証環境では
systemd-timesyncdでもよい - サーバー運用では
chronyの方が確認と制御をしやすい - 内部 NTP サーバーを明示したい場合は chrony が分かりやすい
- 認証基盤や証明書を扱う環境では時刻同期を明示的に管理する
重要なのは、両方を曖昧に併用しないことです。chrony を使うなら chrony を主として、timedatectl と chronyc で状態を確認します。
現在の時刻同期状態を確認する
まず、現在の時刻、タイムゾーン、NTP 同期状態、chrony の有無を確認します。
timedatectl
date
date -u
systemctl status chrony.service --no-pager
chronyc tracking
chronyc sources -vtimedatectl では OS 全体の時刻同期状態を確認できます。chrony を使う場合は、chronyc tracking と chronyc sources -v で同期先、offset、stratum、source の選択状態を確認します。
chrony をインストールする
chrony が入っていない場合は、package をインストールし、サービスを有効化します。
sudo apt update
sudo apt install -y chrony
sudo systemctl enable chrony.service
sudo systemctl start chrony.service
systemctl status chrony.service --no-pagerchrony を導入した後は、systemd-timesyncd と役割が重ならないようにします。環境によっては timesyncd が自動的に使われなくなりますが、実際の同期状態は必ず確認します。
chrony.conf の基本設定
内部 NTP サーバーを使う場合は、/etc/chrony/chrony.conf に参照先を明示します。次は最小構成の例です。
sudo tee /etc/chrony/chrony.conf >/dev/null <<'EOF'
server ntp.example.internal iburst prefer
driftfile /var/lib/chrony/chrony.drift
rtcsync
makestep 1 3
leapsectz right/UTC
logdir /var/log/chrony
EOF
sudo chmod 644 /etc/chrony/chrony.confserver には参照する NTP サーバーを指定します。内部 NTP を使う環境では、外部 NTP へ直接出すより、内部の時刻基盤へ向ける方が管理しやすくなります。
主要な設定項目
| 設定 | 意味 |
|---|---|
server ... iburst prefer | 参照する NTP サーバーを指定する |
driftfile | 時計のずれ傾向を保存する |
rtcsync | system clock を RTC へ反映する |
makestep 1 3 | 起動直後などの大きな時刻ずれを補正する |
logdir | chrony のログ出力先を指定する |
makestep は、起動直後に大きくずれている時刻を段階的な補正ではなく step で合わせる設定です。常時大きく時刻を飛ばすための設定ではなく、起動直後の補正として考えます。
設定を反映する
設定を変更したら chrony を再起動し、同期状態を確認します。
sudo systemctl restart chrony.service
systemctl status chrony.service --no-pager
chronyc tracking
chronyc sources -v
chronyc activitychronyc sources -v で、参照先の先頭に ^* が付いていれば、現在選択されている同期元です。^? のように見える場合は、到達性や DNS、firewall を確認します。
DNS と firewall を分けて確認する
NTP サーバーを FQDN で指定している場合、名前解決できないと chrony は参照先へ到達できません。また、UDP/123 が firewall や経路上で止まっていても同期できません。
getent hosts ntp.example.internal
resolvectl query ntp.example.internal
ip route get 10.0.10.123
sudo nft list ruleset
chronyc sources -v
journalctl -u chrony.service -n 100 --no-pagerDNS の問題なのか、経路の問題なのか、firewall の問題なのか、chrony の設定の問題なのかを分けます。名前で引けない場合は systemd-resolved、IP で届かない場合は route / nftables、chrony 側の選択状態は chronyc sources -v で確認します。
proxy 環境での注意
NTP は HTTP proxy を経由する通信ではありません。proxy 環境で外部 HTTP / HTTPS だけを許可している場合、NTP は別途許可が必要です。
- NTP は通常 UDP/123 を使う
- HTTP proxy を設定しても NTP 通信には効かない
- 外部 NTP を使うのか、内部 NTP を使うのかを決める
- 閉域環境では内部 NTP を用意する方が切り分けしやすい
外部通信を制限する環境では、サーバーが直接外部 NTP へ出る設計ではなく、内部 NTP へ集約する方が自然です。これは監査や firewall 設計の観点でも扱いやすくなります。
トラブル時に見るポイント
timedatectlで NTP 同期状態を確認するchronyc trackingで offset や stratum を確認するchronyc sources -vで同期元が選ばれているか確認する- NTP サーバー名が DNS で引けるか確認する
- NTP サーバーへの route と firewall を確認する
journalctl -u chrony.serviceでエラーを見る- VM や host の時刻設定が過度に干渉していないか確認する
時刻同期の障害は、認証や証明書の障害として表面化することがあります。ログインできない、証明書が不正に見える、ログの順序が合わない場合は、時刻同期も早い段階で確認します。
参考書籍
関連する記事
まとめ
Ubuntu 26.04 で chrony を使うと、NTP による時刻同期を明示的に管理できます。サーバー運用では、時刻同期はログ、証明書、認証、監査、分散システムの前提です。
重要なのは、chrony を入れることだけではありません。どの NTP サーバーを参照するのか、DNS で引けるのか、UDP/123 が通るのか、同期元が選ばれているのかを確認することです。時刻同期は地味ですが、Ubuntu 26.04 の運用基盤として非常に重要な設定です。



