「service ntpd restart」と「ntpdate <ntp-server-ip>」は同じように機能しますか？
ntpq -pを使用してntpdをチェックするときに大きなオフセットを取得することがよくあります。通常、ntpデーモンを再起動すると問題が修正されます。 ntpdを再起動する代わりにntpdate <ntp-server-name>を試すことができるかどうか知りたいと思いました。これはプロダクションボックスなので、実装する前に確認する必要がありました。
ntpdateとntpdは異なるツールですが、1つは別のツールを助けます。
ntpdateは、システムクロックをすぐに同期するために使用されます。ステータスが同期されているntpdサーバーからは時間がかかります（層1〜4）。
ntpdサービスはシステムクロックを設定しますsoftly。システムクロックの数分の遅れを解消するために数時間を費やす場合があります。この間、ステータスは同期されていますstratum 16-システムクロックが同期されていないことを意味します。サービス再起動コマンドservice ntpd restartは、構成ファイルの変更を適用するためにのみ使用されます。
ntpdateは通常、起動時にパーソナルコンピュータのシステムクロックを同期するために使用されます。 ntpdサービスは通常、サーバーのシステムクロックを常時同期するために使用されます。
いいえ。引用man ntpdate：
NTPサーバーデーモン（ntpdなど）が同じホストで実行されている場合、ntpdateは日付の設定を拒否します。デーモンを実行する代わりに、cronから定期的にntpdateを実行する場合、 1時間または2時間に1回行うと、時計のステップを回避するのに十分な正確な計時が行われます。
さまざまな一般的に使用されているLinuxディストリビューション（CentOS、Debian、Ubuntuなど）では、ntpdはデフォルトで-gフラグで開始されます。つまり、必要に応じて最初の調整で大きなクロックステップを実行します。 。したがって、ほとんどの場合、ntpdateは不要であり、ntpdを再起動することをお勧めします。
しかし、Svenがコメントしたように、ntpdがしばらく実行されていて、それでも大きなオフセットが発生する場合は、NTP設定またはネットワーク（またはその両方）に問題があります）。
そのため、ntpdを再起動したり、ntpdateを実行したりするのではなく、最初にこの状況に陥った理由を診断してみてください。
いくつかの一般的な問題：
- 十分なピアが含まれていません- 少なくとも4つ 必要です。時間があれば、BCPドラフト全体を読んでください。
- 新しい
serverディレクティブの代わりに public NTP pool でpoolを使用する-ntpdがサポートしている場合は、後者を使用する必要があります。 - 遠すぎるか接続が不十分なピアを使用する-近くの信頼できるピアを選択してください。さらに、ネットワークのローカル基準クロックで外部ピアを増強します。 （環境によっては、GPSレシーバーを備えたBeagleBone、Raspberry Pi、またはLeoNTPが適している場合があります。）
- サーバーが カーネルバグ やハードウェアクロックの不良など、良い時間を維持するのに苦労している他の理由が考えられます。
ntp.confでloopstats、peerstats、sysstatsを有効にすると、これを追跡しやすくなります。
設定とntpq -npからの出力を投稿してください。うまくいけば、これを解決するのに役立つはずです。