Linuxの時刻同期・時刻ずれの確認手順｜chrony・timedatectl・NTP
Linuxサーバーの時計がずれる、NTP同期状態が不明、同期サービスが動いていないときに、設定を変更する前に管理方式を特定し、時刻・同期元・通信・ログの順で安全に切り分けます。
このページの目的
「時刻が違う」をタイムゾーンの表示差と時計そのもののずれに分け、さらにchrony・systemd-timesyncd・ntpdのどれが時刻管理しているかを確認します。
最初にやること
date -uとtimedatectl statusで表示と同期状態を記録し、管理サービスを特定した後にchronyならchronyc trackingとchronyc sources -vで同期元を確認します。
関連するLinux障害調査ガイド
journalctlでエラーを確認する
NTPクライアントの起動失敗や同期エラーを、起動回・サービス・時刻で絞り込む手順です。
ログを確認 → DNS障害NTPサーバー名が解決できない
同期先にホスト名を使っていて名前解決が失敗する場合、DNS設定と実効経路を切り分けます。
DNSを切り分ける → Linux通信経路・ネットワークの確認
同期先のIPアドレスまでの経路やFirewallなど、時刻管理サービス以外の通信問題を確認します。
通信経路を確認 →chronyc makestepや手動時刻変更を初手で実行せず、管理主体・影響範囲・変更手順を確認してください。最短の確認順
コマンドが存在しない・特定サービスが未導入でも、直ちに異常ではありません。ディストリビューション、仮想マシン、コンテナなどによって管理方式が異なります。すべてのコマンドが使えることを期待しないのが重要です。
1. 「時間が違う」はタイムゾーンか時計のずれか
dateは通常ローカルタイム、date -uはUTC表示です。timedatectl statusでTime zone、System clock synchronized、NTP serviceなどを確認します。ローカル表示とUTCの時差は、時計の同期不良を示すものではありません。
| 見え方 | 次に確認すること |
|---|---|
| UTC表示は妥当だがローカル表示だけ違う | timedatectlのTime zoneと運用で要求される表示タイムゾーンを比較 |
| UTC自体が正しい時刻からずれている | 実際の時計ずれを疑い、同期管理方式と参照先を確認 |
System clock synchronized: no | 管理サービス・同期元・ログを確認。「no」だけで原因や精度を断定しない |
タイムゾーン変更が必要でも、監視・ログ・アプリケーション側の想定が一致するか確認してから変更します。タイムゾーン変更とNTP同期操作は別の作業です。
2. どのサービスが時刻を管理しているか
RHEL系ではchronyd、Debian/Ubuntu系ではchronyというUnit名がよく使われます。環境によってはsystemd-timesyncdや旧ntpd、仮想化・クラウドのゲスト機構が関わる場合もあります。
3. chronyを使っている場合
chronyc trackingでは、Reference ID、System time、Last offset、Root delay、Root dispersion、Leap statusなどを確認します。Leap status: Normalは同期評価の重要な材料ですが、アプリが求める精度を満たすかは別途判断します。
| 代表項目 | 読み方・次の確認 |
|---|---|
System time | 参照時刻に対して残っているシステム時計補正量の目安。大きい場合は収束中か履歴・変化を観測 |
Leap status: Not synchronised | 同期未完了。sources -v、通信、設定、ログを確認 |
^*（sources） | 選択中のNTPサーバーを示す。到達性やサンプルの偏りも合わせて確認 |
^?（sources） | 利用可能な測定情報がない等の状態。DNSだけでなくネットワーク・未到達・選定状態も確認 |
Reach | 直近の問い合わせ応答履歴を示す8進表記。継続して0なら到達性・同期先・Firewallを点検 |
例えば^*があっても、それだけで要求精度や安定性の保証にはなりません。複数回のtrackingと監視値、元の障害時刻を比較してください。
4. systemd-timesyncdを使っている場合
timedatectl timesync-statusとshow-timesyncは、systemd-timesyncd向けの確認方法です。chronyが管理している環境でこのコマンドが有用な結果を返さなくても、chronyの故障を示すわけではありません。
同期先・Poll interval・Offsetなどの実効状態と、サービスのjournalを突き合わせて確認します。timesync-statusが利用できない古いsystemdでは、状態とjournalを中心に確認してください。
5. 旧来のntpd・systemd非採用環境
旧来の環境ではntpdやSysV initで管理される場合があります。ntpq -pnはntpd向けで、chronyの同期状態の代わりにはなりません。環境のサービス管理方式を確認してから対応するコマンドを使います。
6. 同期元、通信、ログから原因を絞る
ntp.example.netと192.0.2.10は説明用の例です。実際には設定済みの同期先へ置き換えます。NTPの通常の通信先ポートはUDP/123です。UDPはTCP接続テストとは異なるので、nc -vzの成功・失敗だけでNTP到達性を判断しません。
DNS名を使っていて解決できないならDNS名前解決の切り分けへ、ルート自体がおかしいならネットワーク疎通確認へ進みます。
7. 確認結果ごとに次の対処を決める
| 確認結果 | 次の対処・注意 |
|---|---|
| タイムゾーンだけが異なる | 要件に合うTime zoneへ統一する計画を立てる。ログ時刻・ジョブ実行時刻の影響を確認してから変更 |
| 時刻同期サービスが停止／未導入 | OSの標準方式・構成管理元・クラウド側同期機能を確認。既存方式と競合しない場合に限り担当サービスの有効化・起動を計画 |
sourcesに利用可能な同期元がない | 同期サーバー設定、名前解決、UDP/123の通信経路、Firewall、サーバー側の公開範囲を調査 |
| 同期元は選択されているがoffsetが大きい | 複数回のtrackingで収束するか観測。急な時刻変更やmakestepは変更承認・影響確認後に判断 |
| 仮想マシンやコンテナだけで時刻が異常 | ゲストエージェント、ホスト側の時刻、仮想化・オーケストレーションの管理方針を確認。コンテナ内から安易に時計を変更しない |
| 証明書・認証だけ失敗 | 時計とUTCのずれに加え、DNS、証明書の有効期間、認証サービスの許容スキューを切り分ける |
8. 修正後は時刻・同期元・ログを再確認する
対処前後で同じ確認値と取得時刻を比較します。同期元が選択され、ずれが環境の許容範囲に収束し、時刻同期サービスのエラーが再発していないことを確認してください。必要なら監視やログで数周期の安定性を観測します。
解決しない場合は、管理方式・同期元名/IP・関連ログの時刻・ネットワーク経路を整理し、journalctlガイドや環境固有の公式手順で追加調査します。