サーバーインフラストラクチャの運用において、正確な時刻同期（NTP）の維持は極めて重要なタスクです。ログファイルのタイムスタンプ整合性、データベースのトランザクション管理、SSL/TLS証明書の有効期限検証、そして各種分散システムの認証エラー（Kerberos等）に至るまで、時刻のズレはシステム全体を致命的な障害に陥れる原因となります。
RHEL 9系をベースとするAlmaLinux 9では、従来のNTPデーモン（ntpd）に代わり、より高速かつ不安定なネットワーク環境でも精度の高い同期を実現する「chrony（クロニー）」が標準の時刻同期サービスとして採用されています。
リナックス先生、運用中のAlmaLinux 9サーバーで、「システム時刻が外部のNTPサーバーと同期していない」というアラートが検知されました。chronyd を再起動してみたんですが、一向に同期が完了しません。どこをどう調べればいいのか、トラブルシューティングの手順を教えてください！
コウ君、時刻同期のトラブルはインフラの現場で頻発する定番のインシデントですね。chronyは非常に優秀ですが、ファイヤーウォールの設定ミス、上流NTPサーバーの応答不良、あるいはローカルクロック自体のドリフト（ズレ）が大きすぎると同期を拒絶します。プロのインフラエンジニアとして、下位レイヤーから順を追って原因を切り分ける「体系的な診断フロー」を実践しましょう。
本記事では、AlmaLinux 9環境におけるchronyの挙動を完全に把握し、時刻同期エラーが発生した際に迅速に原因を特定して復旧させるための実践的なトラブルシューティング手順を徹底解説します。
目次
1. 診断の第一歩：chronyのステータスと同期状態の確認
時刻同期に関するインシデントが発生した際、まず最初に確認すべきなのは「現在の同期状態がどうなっているか」です。chronyには、詳細な統計情報をリアルタイムで取得するための強力なCLIツール（chronyc）が用意されています。
1.1. chronydサービスの稼働確認
まずは、バックグラウンドでデーモン自体が正常に起動しているかを systemctl で確認します。
# chronydサービスの稼働状態を確認
sudo systemctl status chronyd出力結果のステータスが active (running) であることを確認します。もし停止している場合は sudo systemctl enable --now chronyd で起動を試みますが、後述する設定エラーやポート競合が原因で起動直後にクラッシュする場合があるため、後続のログ確認が必須です。
1.2. chronycトラッキング情報の確認
次に、ローカルシステムが現在どの程度正確に時刻を維持しているか、どのサーバーソースに追従しているかを chronyc tracking コマンドで診断します。
# システムの時刻同期トラッキング情報を表示
chronyc tracking【注目すべき出力項目】
- Reference ID： 同期している上流NTPサーバーのIPアドレス（または識別子）。ここが
127.0.0.1（LOCL）のまま変化しない場合、外部のNTPサーバーと全く通信できていません。 - System time： 真の時刻との誤差。ここが数秒以上離れている場合、chronyの通常の微調整（スルーモード）では追いつかなくなっている可能性があります。
- Stratum（階層）： サーバーの階層。通常のNTPクライアントであれば 2〜4 程度の数値になります。
1.3. 同期ソース（NTPサーバー）の一覧確認
どのNTPサーバーを参照しに行っているか、現在接続が確立されているかを chronyc sources で確認します。
# 登録されているNTPソースの一覧と状態を表示
chronyc sources -v【ステータス記号の見方（行頭の記号）】
^\*（アスタリスク）：現在、正常に時刻同期を行っているアクティブなソース。これが1つも存在しない場合、同期異常が発生しています。^\+（プラス）：候補として選ばれている良好なソース。^\?（クエスチョン）：接続がロストしている、または応答がないソース。
2. トラブルシューティング手順①：NTPサーバーとの疎通とパケット確認
chronyc sources ですべてのソースが ?（応答なし）になっている場合、多くはネットワーク層、あるいはファイアウォール層に原因があります。NTPはUDPの「123番ポート」を使用します。
2.1. UDP 123番ポートの疎通確認
上位のNTPサーバー（例：pool.ntp.org や社内の内製NTPサーバー）に対して、UDPパケットが正しく届いているかを検証します。
# chronycを用いて、サーバーとの往復遅延と到達性を強制テスト
chronyc sourcestats -vまた、ネットワークの経路障害やDNS名前解決のトラブルがないかを、基本的なネットワークコマンドで確認します。
# NTPサーバーのドメインが正しく名前解決できるか確認
nslookup ntp.yourcompany.local
# タイムアウトが発生していないか、chronyのログをリアルタイム監視
sudo journalctl -u chronyd -f3. トラブルシューティング手順②：設定ファイル（chrony.conf）の構文検証
管理者が手動で設定ファイルを編集した直後に同期エラーが発生した場合、設定ミス（ディレクティブの記述間違い、IPアドレスのタイポなど）が疑われます。
AlmaLinux 9におけるchronyの設定ファイルは /etc/chrony.conf です。
 | 本気で学ぶ Linux実践入門 サーバ運用のための業務レベル管理術 [ 大竹龍史 ] 価格:3278円 |
# 設定ファイルの主な記述例
server ntp.almalinux.org iburst
server time.google.com iburst
# ローカルネットワークからのアクセス許可（タイムサーバーとして動作させる場合）
allow 192.168.10.0/243.1. よくある設定ミスとチェックポイント
- iburstオプションの欠落： サーバー起動直後、最初の一回目の同期を高速化するための
iburstキーワードが抜けていると、同期完了までに非常に長い時間がかかります。 - ドメイン名のタイポ： サーバ名のスペルミスにより名前解決に失敗している場合、chronydは起動時にエラーログを吐き出します。
設定ファイルを変更した際は、必ずサービスを再起動する前に構文エラーがないかログを確認するか、サービス再起動コマンドを実行してステータスにエラーが出ていないかを厳重にチェックしてください。
4. トラブルシューティング手順③：ファイアウォール（firewalld）とSELinuxの確認
「パブリッククラウドからオンプレミス環境へ移行した際」「セキュリティポリシーを強化した直後」に最も頻発するのが、AlmaLinux 9の標準パケットフィルタリング機能によるブロックです。
4.1. firewalldにおけるNTPサービスの許可
自社サーバーを「タイムサーバー（NTPサーバー）」として外部や社内クライアントに時刻を提供するように構成している場合、外部からのUDP 123番ポートへのアクセスをfirewalldが許可していなければ、クライアント側から見て「同期不可」となります。
# firewalldでNTPサービスを永続的に許可
sudo firewall-cmd --add-service=ntp --permanent
# 設定を即時反映させるためリロード
sudo firewall-cmd --reload
# 現在のファイアウォール設定を確認
sudo firewall-cmd --list-services※なお、単に「外部のNTPサーバーから時刻を受け取る（クライアントとして動作する）」だけの一般的な構成であれば、発信トラフィック（Outbound）は原則としてデフォルトで許可されているため、firewalldの設定変更は不要です。
4.2. SELinuxの拒否ログチェック
厳格なセキュリティポリシーを持つAlmaLinux 9において、chronydが意図しないファイルやポートにアクセスしようとした場合、SELinuxが沈黙のままブロック（AVC Denial）を起こすことがあります。
# SELinuxによるchronyd関連の拒否ログを抽出
sudo ausearch -m avc -c chronyd
# または、audit.logから直接検索
sudo grep chronyd /var/log/audit/audit.logもしSELinuxに起因するブロックが検出された場合は、カスタム設定を追加するか、システム標準のポリシーに準拠したパスに変更する必要があります。
5. 緊急時の強制同期（ステップ同期）と再起動フロー
ここまでの診断と修正を行っても、「システム時計のズレが大きすぎて（例：数分〜数時間ズレている）、chronyの通常のスルーモード（徐々に合わせる方式）では同期が追いつかない」という緊急事態が発生することがあります。この場合、強制的に時刻を上書きする「ステップ同期」を実行します。
5.1. chronycを用いた手動での強制同期
サービスを再起動することなく、即座に外部NTPサーバーの時刻をシステム時計に強制適用するコマンドです。
# 上流サーバーの時刻を強制的に即時反映させる（ステップ同期）
sudo chronyc -a makestep実行後、直ちに chronyc tracking を実行し、「System time」の誤差が数ミリ秒以内に収まったことを確認します。
5.2. クリーンな再起動と状態リセットのフロー
状態が完全に迷子になっている場合は、chronydのプロセスを再起動し、キャッシュやトラッキング状態をリセットするのが最も確実です。
# chronydサービスの完全再起動
sudo systemctl restart chronyd
# 再起動直後の同期ソース状態をトラッキング
chronyc sources -v⚠️ 注意：仮想マシン（KVM / VMware等）における時刻ドリフト
AlmaLinux 9が仮想マシン（VM）として稼働している場合、ホストOS側の負荷が高騰すると、ゲストOS側のタイマーが一時的に停止・遅延し、chronyが同期エラーを起こすことがあります。仮想環境では、ゲストOS側に適切なゲストツール（QEMU Guest AgentやVMware Tools）を導入し、ホストOSとの時刻同期ドリフトを抑制するハイパーバイザー側の設定が不可欠です。
6. まとめと予防保全のベストプラクティス
本記事では、AlmaLinux 9環境におけるNTP（chrony）のトラブルシューティング手法について、以下のステップで徹底解説しました。
- 状態の可視化：
chronyc trackingやchronyc sources -vを用い、アクティブな同期ソースとシステム誤差を迅速に把握する。 - ネットワークとファイアウォールの診断： UDP 123番ポートの疎通性と、firewalldの許可設定を確認する。
- 設定とセキュリティ：
/etc/chrony.confの構文ミスや、SELinuxによるブロックを監査ログから特定する。 - 緊急復旧：
chronyc -a makestepによる強制ステップ同期と、サービス再起動による状態リセットを行う。
時刻同期のトラブルはシステムの根幹を揺るがす隠れた爆弾です。日頃からPrometheus等の監視基盤と連携し、chronyの同期ステータスやオフセット量を監視・アラート化しておくことが、エンタープライズインフラを安定運用するための最高の予防保全となります。
▼ 【安定したインフラ環境を構築しよう】 ▼
時刻同期が安定する高信頼サーバー
「高コスパおすすめVPS・専用サーバー」
インフラ運用のスペシャリストを目指す
「インフラエンジニア専門転職」
コメント