- 1 1. Ubuntuで時刻同期が重要な理由
- 2 2. ntpdateとは何か
- 3 3. なぜ「ubuntu ntpdate」で検索され続けるのか
- 4 4. Ubuntuのバージョン別 ntpdate の扱い
- 5 5. 現在のUbuntuで推奨される時刻同期方法
- 6 6. それでも ntpdate を使いたい場合
- 7 7. よくあるエラーと対処法
- 8 8. 結論｜Ubuntuでの正しい時刻同期の考え方
- 9 9. よくある質問（FAQ）
1. Ubuntuで時刻同期が重要な理由
1.1 Linuxサーバーにおける「時刻」は基盤情報
UbuntuをはじめとするLinux環境では、時刻は単なる表示情報ではなく、システム全体の前提条件として扱われます。
サーバー内部では、ほぼすべての処理が「現在時刻」を基準に動いており、この時刻がずれていると、見た目以上に深刻な問題を引き起こします。
特にUbuntuは、サーバー用途・クラウド用途で利用されることが多く、
時刻のズレは以下のような領域に直接影響します。
1.2 時刻がずれることで発生する具体的な問題
ログの整合性が崩れる
システムログやアプリケーションログは、すべてタイムスタンプ付きで記録されます。
時刻がずれていると、
- エラー発生の前後関係が分からない
- 障害解析が困難になる
- 複数サーバー間でログを突き合わせられない
といった問題が発生します。
特に分散システムでは、正確な時刻同期ができていないだけでトラブルシュートが不可能になるケースもあります。
SSL証明書・セキュリティ機能が正常に動作しない
HTTPS通信で使われるSSL/TLS証明書は、有効期限を厳密にチェックします。
サーバー時刻がズレていると、
- 「証明書が無効です」
- 「まだ有効になっていません」
といったエラーが発生し、通信そのものが拒否されることがあります。
これはWebサーバーだけでなく、API通信やパッケージ管理（apt）などにも影響します。
cronやsystemdタイマーが誤動作する
Ubuntuでは定期処理として、
- cron
- systemd timer
が広く使われています。
時刻がずれていると、
- 実行されるはずのジョブが動かない
- 想定外の時間に処理が走る
といった問題が起きます。
バックアップやバッチ処理など、気付きにくいが致命的なトラブルにつながる点です。
1.3 クラウド・VPS環境で特に重要な理由
近年のUbuntu利用環境は、
- VPS
- クラウド（IaaS）
- 仮想マシン
が主流です。
これらの環境では、ホストOSとゲストOSの時刻管理が分離されており、以下のような要因でズレが生じます。
- 仮想化基盤の影響
- サスペンド／再開
- 高負荷時のクロック遅延
そのため「インストール直後は合っていたが、気付いたら数分ずれていた」ということも珍しくありません。
このような背景から、Ubuntuでは自動かつ継続的な時刻同期が前提設計となっています。
1.4 なぜ「ntpdate」を探す人が多いのか
時刻がずれたとき、検索エンジンで
「ubuntu 時刻 同期」
「ubuntu ntpdate」
と調べる人は非常に多いです。
その理由は、
- 以前はntpdateが定番だった
- 古い記事や回答が今も大量に残っている
- 「一発で直せそう」という印象が強い
といった事情があります。
しかし、現在のUbuntuでは時刻同期の考え方自体が変わっているため、
単純にntpdateを実行すれば良い、という話ではなくなっています。
2. ntpdateとは何か
2.1 ntpdateの基本的な役割
ntpdate は、Linux環境で長年使われてきた時刻同期用のコマンドラインツールです。
指定したNTPサーバー（時刻配信サーバー）に問い合わせを行い、現在のシステム時刻を一度だけ同期します。
最大の特徴は次の点です。
- 常駐しない
- 実行した瞬間に時刻を合わせる
- 設定が非常にシンプル
そのため、初心者でも「コマンドを1回実行するだけで直る」という印象を持ちやすく、
トラブル対応時の即席ツールとして広く使われてきました。
2.2 ntpdateの動作イメージ
ntpdateの動作は非常に単純です。
- 指定したNTPサーバーに現在時刻を問い合わせる
- ローカルマシンの時刻との差分を計算する
- その差分を元に、時刻を一気に修正する
このため、数秒〜数分単位のズレであれば即座に修正できます。
ただし、内部的には「強制的に時刻を動かす」ため、
実行中のプロセスやサービスへの影響が出る可能性もあります。
2.3 ntpdや他のNTPサービスとの違い
ntpdateは、しばしば ntpd（NTPデーモン）と混同されますが、役割は明確に異なります。
ntpdate wp:list /wp:list
- 単発実行
- 時刻を一気に修正
- 常駐しない
ntpd（NTPデーモン） wp:list /wp:list
常駐サービス
- 時刻を徐々に補正
- 長期的な安定性を重視
サーバー運用の観点では、常駐型の方が安全であり、
ntpdateは「補助的な道具」という位置づけでした。
2.4 なぜntpdateは広く使われてきたのか
ntpdateが長年支持されてきた理由は明確です。
- コマンドが分かりやすい
- 設定ファイルが不要
- 初期構築時にすぐ使える
- ググると必ず出てくる
特に、
- OSインストール直後
- 大きく時刻がずれた直後
- NTPサービスが止まっている状況
といった場面では、「まずntpdateを打つ」という運用が定番でした。
2.5 現代のUbuntuとのズレ
問題は、Ubuntuの内部設計が進化したにもかかわらず、ntpdateの使い方だけが過去のまま残っている点です。
現在のUbuntuでは、
- systemdによる時刻管理
- 自動同期前提の設計
- 常駐型サービスの統合管理
が基本となっています。
その結果、
- ntpdateが標準で入っていない
- 実行すると警告や競合が発生する
- 「非推奨」という扱いになる
という状況が生まれました。
2.6 「ntpdate＝間違い」ではないが注意が必要
ここで重要なのは、
ntpdateそのものが間違いというわけではない、という点です。
- 使いどころを理解していれば有効
- ただし常用するものではない
- 現代Ubuntuの主役ではない
という立ち位置に変わった、と理解するのが正確です。
3. なぜ「ubuntu ntpdate」で検索され続けるのか
3.1 検索される理由は「困っているから」
「ubuntu ntpdate」という検索キーワードには、はっきりした共通点があります。
それは、多くの場合 時刻同期に関するトラブルがすでに発生している という点です。
たとえば、
- サーバーでSSLエラーが出た
- cronが動かない
- ログの時刻がおかしい
- パッケージ更新が失敗する
こうした問題に直面したとき、
「Ubuntu 時刻 同期」「Ubuntu ntpdate」と検索する人は非常に多いです。
3.2 過去の情報が現在も大量に残っている
ntpdateが使われていた期間は非常に長く、
その結果として、
- 古いブログ記事
- Q&Aサイトの回答
- 技術書の記述
- QiitaやStack Overflowの投稿
が、今も検索結果に大量に表示されます。
特に「とりあえずこれを打てば直る」という文脈で紹介されているケースが多く、
検索した人は深く考えずに実行してしまいやすい構造になっています。
3.3 Ubuntu公式ドキュメントとのギャップ
現在のUbuntu公式ドキュメントでは、
時刻同期は以下を前提に説明されています。
- systemd-timesyncd が標準
- 常駐サービスによる自動同期
- 手動での強制修正は原則不要
しかし、初心者にとっては、
- 「systemdって何？」
- 「設定が難しそう」
- 「今すぐ直したい」
という心理が働きます。
その結果、説明が少なく即効性のあるntpdateに流れやすいのです。
3.4 エラーメッセージが検索を誘発する
Ubuntu 20.04以降でntpdateを実行しようとすると、
command not found- パッケージが存在しない
- 非推奨の警告
といったメッセージに遭遇します。
このとき多くの人は、
- 「なぜ使えないのか？」
- 「代わりは何なのか？」
- 「自分の環境がおかしいのか？」
と疑問を持ち、再び
「ubuntu ntpdate」
で検索します。
こうして、検索が自己増殖する構造が生まれています。
3.5 バージョン差を意識していないケースが多い
UbuntuはLTSを中心に長期間使われるため、
- 16.04
- 18.04
- 20.04
- 22.04
- 24.04
といった異なる世代が混在しています。
ところが、検索する側は自分のUbuntuバージョンを意識せず、
「Ubuntuなら同じだろう」と考えがちです。
結果として、
- 古い解決策を新しいUbuntuで試す
- うまくいかず、さらに混乱する
という流れが生まれます。
3.6 検索キーワードとして残り続ける構造
まとめると、「ubuntu ntpdate」が検索され続ける理由は次の通りです。
- 時刻同期トラブルは今も頻繁に起きる
- ntpdateの知名度が非常に高い
- 古い情報が消えずに残っている
- Ubuntuの設計変更が十分に伝わっていない
このため、実態としては非推奨であっても、検索キーワードとしては生き続けているのです。
4. Ubuntuのバージョン別 ntpdate の扱い
4.1 Ubuntu 16.04 / 18.04 時代の ntpdate
Ubuntu 16.04 や 18.04 の頃は、
ntpdate は 実用的かつ一般的な選択肢でした。
この時代の特徴は次の通りです。
- ntpdate パッケージが公式リポジトリに存在
- ntpd と併用されるケースが多い
- 初期同期やトラブル対応で頻繁に使われていた
特にサーバー構築直後、
- 時刻が大きくずれている
- ntpd が安定する前に同期したい
といった場面では、ntpdate は非常に便利でした。
4.2 Ubuntu 18.04 以降で始まった変化
Ubuntu 18.04 では、
内部的に systemd が本格的に採用され始めます。
この流れの中で、
- 時刻管理が systemd 側に統合される
- 常駐型の自動同期が前提になる
- 単発同期ツールの役割が薄れる
といった設計思想の変化が起きました。
この時点では ntpdate はまだ利用できましたが、
「必須ツール」ではなくなりつつありました。
4.3 Ubuntu 20.04 以降での決定的な転換
Ubuntu 20.04 以降では、状況が大きく変わります。
- systemd-timesyncd が標準で有効
- ntpdate はデフォルトでインストールされない
- 非推奨の扱いが明確化
この結果、従来の感覚で ntpdate を実行すると、
- コマンドが見つからない
- パッケージが存在しない
- systemd との競合が起きる
といった問題が発生するようになりました。
ここで重要なのは、
Ubuntuが「単発同期」より「常時同期」を重視する設計に完全に切り替わったという点です。
4.4 Ubuntu 22.04 / 24.04 の現在地
Ubuntu 22.04 や 24.04 では、この方針がさらに明確になっています。
- 時刻同期は自動で行われるもの
- 管理者が意識する必要は最小限
- 特別な事情がなければ手動同期は不要
そのため、公式ドキュメントや推奨構成では
ntpdate の名前がほとんど登場しません。
代わりに、
- systemd-timesyncd
- chrony（高度な用途向け）
が中心的な役割を担っています。
4.5 バージョン差を理解しないと起きる混乱
多くの混乱は、次のようなケースで起こります。
- 古いUbuntuの知識を新しいUbuntuに適用する
- 検索結果の情報がバージョン前提を書いていない
- 自分の環境がどの世代か意識していない
その結果、
「昔はできたのに、なぜ今はできないのか？」
という疑問が生まれます。
しかしこれは、Ubuntuが進化した結果として自然な変化です。
4.6 バージョン別の考え方まとめ
ここまでを簡潔にまとめると、
- 16.04 / 18.04 → ntpdate は実用的だった
- 20.04 以降 → ntpdate は原則不要
- 22.04 / 24.04 → 常駐型同期が前提設計
という整理になります。
5. 現在のUbuntuで推奨される時刻同期方法
5.1 Ubuntuの標準は「自動で常に同期する」設計
現在のUbuntuでは、
時刻は管理者が手動で合わせるものではなく、自動的に維持されるもの
という考え方が基本になっています。
その中心にあるのが、systemd に統合された時刻同期機構です。
- OS起動時に自動で同期
- 稼働中も継続的に微調整
- 特別な設定をしなくても有効
つまり、多くの環境では
すでに正しい時刻同期が動いている 状態です。
5.2 systemd-timesyncd を使う方法（標準構成）
systemd-timesyncdとは何か
systemd-timesyncd は、systemd に組み込まれた
軽量なNTPクライアントです。
特徴は次の通りです。
- 常駐型で自動同期
- 設定が非常にシンプル
- Ubuntuの標準構成に最適化されている
特別な理由がなければ、
まずこの仕組みを使うのが正解です。
時刻同期の状態を確認する
現在の同期状態は、以下のコマンドで確認できます。
timedatectl
ここで注目すべきポイントは、
System clock synchronizedNTP service
の項目です。
これらが有効であれば、
すでに時刻同期は正常に機能しています。
NTPを有効にする方法
もしNTPが無効になっている場合は、
次のコマンドで有効化できます。
sudo timedatectl set-ntp true
これだけで、systemd-timesyncd による自動同期が開始されます。
同期が反映されるまでの注意点
systemd-timesyncd は、
- 起動直後に即座に大きく時刻を変える
- 急激な修正を頻繁に行う
といった挙動は避ける設計です。
そのため、
- 大きくズレている場合
- ネットワーク接続直後
には、数分程度待つ必要がある場合もあります。
5.3 chrony を使うケース
chronyとは何か
chrony は、
高精度・高信頼性を重視した時刻同期ソフトウェアです。
以下のような環境で使われることが多いです。
- サーバー用途
- 長時間稼働
- 不安定なネットワーク環境
- 仮想環境やコンテナ環境
systemd-timesyncdとの違い
両者の違いを簡単に整理すると、
systemd-timesyncd wp:list /wp:list
- 軽量
- 設定が簡単
- 一般用途向け
chrony wp:list /wp:list
高精度
- 細かい制御が可能
- サーバー運用向け
通常のデスクトップや小規模サーバーであれば、
systemd-timesyncd で十分です。
chronyが向いているケース
次のような条件に当てはまる場合は、chronyを検討する価値があります。
- 時刻精度が業務要件に直結する
- NTPサーバーを自前で運用している
- 仮想化環境で時刻ズレが頻発する
逆に言えば、
「ntpdateの代わり」として安易にchronyを選ぶ必要はありません。
5.4 なぜ「常駐型」が推奨されるのか
現在のUbuntuが常駐型同期を重視する理由は明確です。
- 急激な時刻変更を避けられる
- サービスへの影響が最小限
- 人為的ミスを減らせる
これは、
安定稼働を最優先するサーバー設計思想に基づいています。
6. それでも ntpdate を使いたい場合
6.1 ntpdateを使うべきか判断する考え方
まず大前提として、
通常運用において ntpdate を使う必要はほとんどありません。
しかし、次のような状況では、
一時的な手段として検討されることがあります。
- 初期構築直後で時刻が大きくずれている
- systemd-timesyncd が正常に同期できない
- 何らかの理由で常駐型サービスを止めている
- 検証・一時作業環境で即座に時刻を合わせたい
つまり、ntpdateは
「恒久対策」ではなく「応急処置」として位置付けるのが正しい考え方です。
6.2 一時的に使うケースの具体例
OSインストール直後
仮想マシンやVPSを作成した直後に、
- 数分〜数十分ずれている
- systemd-timesyncdがまだ同期していない
といった状態になることがあります。
このような場合、
一度だけntpdateで時刻を合わせてから、
常駐型同期に任せる、という使い方は理解できます。
大きく時刻がずれてしまった場合
何らかのトラブルにより、
- バッテリー切れ
- 仮想化基盤の不具合
- 手動で時刻を変更してしまった
などの理由で、時刻が大きく狂うことがあります。
この状態では、
常駐型のNTPが正常に補正できないケースもあり、
一度リセットする目的で ntpdate を使うという判断がされることがあります。
6.3 ntpdate をインストールして使う方法
Ubuntu 20.04以降では、ntpdateは標準で入っていません。
使う場合は、明示的にインストールする必要があります。
sudo apt update
sudo apt install ntpdate
実行例は次のようになります。
sudo ntpdate pool.ntp.org
これにより、指定したNTPサーバーと時刻を同期します。
ただし、この操作は一時的なものである点を忘れてはいけません。
6.4 systemdとの競合に注意する
ntpdateを使う際の最大の注意点は、
systemd-timesyncd などの常駐サービスとの競合です。
同時に動かしていると、
- どちらが正しい時刻なのか分からなくなる
- 意図しない時刻変更が発生する
- ログやサービスに影響が出る
といった問題が起きる可能性があります。
そのため、ntpdateを実行する場合は、
- 一時的な利用に限定する
- 実行後は常駐型に戻す
- 常用しない
という運用を徹底する必要があります。
6.5 ntpdateを常用してはいけない理由
ntpdateは便利ですが、
現代のUbuntu環境では次の点で不利です。
- 急激に時刻を変更する
- サービス停止を考慮しない
- 自動管理の思想と合わない
その結果、
「たまに直す」つもりが「不安定にする原因」になりかねません。
6.6 正しい位置付けのまとめ
ntpdateは、
- かつては主役だった
- 今は補助的な道具
- 基本は使わない
という立場に変わりました。
この前提を理解していれば、
必要な場面でのみ、冷静に使うことができます。
7. よくあるエラーと対処法
7.1 ntpdate: command not found と表示される場合
エラーの意味
このエラーは、ntpdate コマンドがシステムに存在しないことを示しています。
Ubuntu 20.04以降では、これは異常ではなく仕様どおりの挙動です。
多くの場合、
- ntpdate が最初からインストールされていない
- 非推奨ツールのため省かれている
という理由によるものです。
対処の考え方
このエラーが出たとき、最初に考えるべきことは、
「本当に ntpdate が必要なのか？」
という点です。
- systemd-timesyncd が有効であれば不要
- 自動同期が動いていれば問題なし
単に「コマンドがないから入れる」のではなく、
現在のUbuntuの設計に沿った方法を優先するのが正しい判断です。
7.2 no server suitable for synchronization found と表示される場合
エラーの意味
このエラーは、
NTPサーバーと正常に通信できなかったことを意味します。
考えられる原因は複数あります。
- ネットワーク未接続
- DNSが正しく動いていない
- ファイアウォールによる遮断
- 指定したNTPサーバーが応答していない
確認すべきポイント
このエラーが出た場合、次の点を順番に確認します。
- インターネットに接続できているか
- 名前解決ができているか
- UDP 123番ポートが遮断されていないか
NTPの問題に見えて、
実際はネットワーク設定の問題であるケースは非常に多いです。
7.3 systemd-timesyncd が同期しない場合
よくある誤解
「時刻が合わない＝壊れている」と考えがちですが、
systemd-timesyncd は即時同期を保証する仕組みではありません。
- 起動直後
- ネットワーク接続直後
- 大きく時刻がずれている場合
には、同期まで少し時間がかかることがあります。
状態確認の考え方
まずは、時刻同期が有効になっているかを確認します。
- NTPが有効か
- サービスが動いているか
- エラー状態になっていないか
多くの場合、少し待つだけで自然に同期されるケースもあります。
7.4 仮想環境特有の時刻ズレ
なぜ仮想環境でズレやすいのか
仮想マシンでは、
- ホストOSの影響
- CPU割り当ての変動
- サスペンド／再開
といった要因で、時刻が不安定になりやすい傾向があります。
これはUbuntuの問題というより、
仮想化環境の特性によるものです。
対処の基本方針
仮想環境では、
- 常駐型の時刻同期を有効にする
- 単発修正を繰り返さない
- ホスト側の時刻も正しく保つ
という方針が重要です。
7.5 「とりあえず ntpdate」は避けるべき理由
エラーが出ると、
「とりあえず ntpdate を実行する」という行動を取りがちですが、
これは根本解決にならないケースが多いです。
- 原因は別にある
- その場しのぎで再発する
- 設計と逆行する
エラー時ほど、
今のUbuntuが前提としている仕組みを理解することが重要です。
7.6 エラー対応のまとめ
時刻同期のエラー対応は、次の順で考えると整理しやすくなります。
- 自動同期が有効か
- ネットワークに問題はないか
- バージョンに合った方法か
- 応急処置が本当に必要か
これを押さえておけば、
ntpdateに振り回されることはなくなります。
8. 結論｜Ubuntuでの正しい時刻同期の考え方
8.1 ntpdateは「昔の正解」、今は主役ではない
かつてのUbuntuやLinux環境では、
ntpdate は時刻同期の定番ツールでした。
- 単純で分かりやすい
- 即座に時刻を合わせられる
- トラブル時の応急処置として便利
このため、今でも記憶や検索結果の中に強く残っています。
しかし、現在のUbuntuでは
OS設計そのものが変わっています。
8.2 現在のUbuntuは「自動・常時同期」が前提
Ubuntu 20.04以降では、
- systemd による統合管理
- 常駐型のNTP同期
- 人が触らなくても維持される設計
が基本となっています。
つまり、
- 手動で時刻を直す
- 定期的にコマンドを打つ
といった運用は、想定されていないのです。
8.3 まず確認すべきは「すでに同期されているか」
時刻に関する問題が起きたとき、
最初にやるべきことは、
- ntpdateを探す
- コマンドを実行する
ではありません。
まず確認すべきなのは、
- 自動同期が有効か
- systemd-timesyncd が動いているか
という点です。
多くの場合、
「すでに正しく動いている」か「少し待てば直る」
というケースがほとんどです。
8.4 ntpdateを使うなら「限定的・一時的」に
それでも ntpdate が必要になる場面はあります。
- 初期構築直後
- 大きく時刻が狂った場合
- 検証や一時作業環境
ただし、その場合でも重要なのは、
- 常用しない
- 自動同期に戻す
- 競合を避ける
という姿勢です。
ntpdateは、
使い方を理解した上でのみ使う補助ツール
という位置付けに変わっています。
8.5 「ubuntu ntpdate」で迷わないために
この記事で伝えたい最も重要なポイントは、次の一文に集約できます。
Ubuntuでntpdateを探す必要がある状況そのものが、すでに例外的である
この前提を理解していれば、
- 古い記事に振り回される
- エラーに過剰反応する
- 不要な設定変更をする
といったことを避けられます。
8.6 正しい選択が安定運用につながる
時刻同期は地味ですが、
サーバーやシステムの信頼性の土台です。
- 自動同期を信頼する
- 現在のUbuntu設計を理解する
- 過去の知識をアップデートする
これが、
安定したUbuntu運用への近道です。
9. よくある質問（FAQ）
Q1. Ubuntuでntpdateはもう使えないのですか？
完全に使えなくなったわけではありません。
ただし、現在のUbuntuでは標準ではインストールされておらず、非推奨の位置付けになっています。
Ubuntu 20.04以降では、時刻同期は systemd-timesyncd による自動・常駐型同期が前提です。
そのため、通常運用で ntpdate を使う必要はありません。
Q2. ntpdateとntpdの違いは何ですか？
両者は役割が異なります。
- ntpdate 一度だけ時刻を強制的に合わせるツール
- ntpd 常駐して時刻を少しずつ補正するサービス
現在のUbuntuでは、ntpdの代わりに
systemd-timesyncd や chrony が使われています。
Q3. systemd-timesyncdとchronyはどちらを使うべきですか？
ほとんどの環境では systemd-timesyncdで十分です。
chronyが向いているのは、次のようなケースです。
- 時刻精度が業務要件に直結する
- サーバーを長期間稼働させる
- 仮想環境で時刻ズレが頻発する
「ntpdateの代わり」として、
必ずしもchronyを選ぶ必要はありません。
Q4. 仮想マシンで時刻がずれやすいのはなぜですか？
仮想環境では、
- ホストOSの影響
- CPU割り当ての変動
- サスペンド／再開
などにより、物理マシンよりも時刻が不安定になりやすい傾向があります。
そのため、常駐型の自動時刻同期を有効にしておくことが重要です。
Q5. systemd-timesyncdが有効なのに時刻が合わないことがあります
systemd-timesyncd は、
急激な時刻変更を避ける設計になっています。
そのため、
- 起動直後
- ネットワーク接続直後
- 大きく時刻がずれている場合
には、同期が完了するまで少し時間がかかることがあります。
多くの場合、しばらく待てば自然に同期されます。
Q6. ntpdateを使っても問題ない場面はありますか？
次のような限定的な場面では、理解した上で使われることがあります。
- OS初期構築直後
- 時刻が大きく狂ってしまった場合
- 検証・一時作業用の環境
ただし、常用は避け、
実行後は自動同期に戻すことが重要です。
Q7. 時刻同期を無効にしたい場合はどうすればよいですか？
検証環境などで意図的に無効化したい場合は、
NTPを無効にすることができます。
ただし、これは特殊な用途向けであり、
通常のサーバー運用では推奨されません。
無効化すると、
- SSLエラー
- ログ不整合
- 定期処理の誤動作
といった問題が発生しやすくなります。
Q8. 結局、初心者は何を覚えておけば良いですか？
初心者の方は、次の3点だけ覚えておけば十分です。
- Ubuntuは自動で時刻同期する設計
- ntpdateは今は主流ではない
- まずは自動同期が有効か確認する
これだけで、
「ubuntu ntpdate」で迷うことはほとんどなくなります。
