ntpd は timesyncd と同様に、動的ネットワーク構成をうまく処理します。いいえ動的ネットワーク構成を扱うときに、実際のNTPデーモンが自動的に正しい操作を実行するときにこの問題を解決するためにスクリプトを使用することは意味がないと思います。 ntpdate（およびtlsdateなどの他のソフトウェア）はスタンドアロンツールには適していますが、自動的に呼び出すのは賢明ではないようです。 （また、起動やネットワークの変更時にのみ更新するよりも、時間を常に最新の状態に保つ方が合理的です。）
私は議論の少なくとも一部を理解しています。最新のPCでは、軽量デーモンを実行して時計を正確に保つのが合理的です。
ネットワーク構成は動的であり、NTPデーモンは特定のネットワーク構成システムと統合されないと仮定します。一般的なインターフェース（一部のLinuxカーネルインターフェースを含む）のみを使用してください。これを行うには何が必要ですか？
歴史的に、ネットワークシステムにスクリプトを実行させることで具体的に統合するのが一般的でした。ところで検索してみるとsystemd-networkdスクリプトフックが実装されていないようです。上記のリンクを見ると、少なくとも開発者がスクリプトフックをあまり好きではないことがわかります。
この質問は少し仮定的です。同様の問題を念頭に置いているので、NTPがこの問題をどのように処理するかを知りたいです。
ＮＴＰを同期しようとする初期試行が失敗したと判断された場合、１時間後に再試行するなどの簡単なアプローチで十分であると仮定する。 [*]
a) 私の質問は、始めようとする時期をどのように検出するかです。これは、NTPクライアントを使用するように構成したサーバーによって異なる可能性があると思います。例えば
- DNSサーバーが構成されていますか？
- DNSサーバーへのルーティングを設定しましたか？ （デフォルトのルーティングは問題ありませんが、すべての状況で動作しない可能性があります。）
- DNSサーバーですか？このインターフェースの場合構成されており、アクセス可能ですか？ （たとえば、複数のインターフェイスで非グローバルDNS名のsystemd-networkdサポートを使用している場合）
- /etc/hostsやMDNSを使用するなど、DNSサーバーを使用せずにNTPサーバーのホスト名が解決されますか？
- NTPサーバーへのルーティングを設定しましたか？
b) pool.ntp.org サーバーに対して礼儀を設ける必要があります。もしそうなら、すべての可能なネットワーク設定イベントが発生した直後に再試行したくないようです。
systemd-resolvedc）DNSサーバーが構成されているときにそれを検出する（またはNetworkManager + dnsmasqまたは...）、そのネットワーク構成システムとの特定の統合が必要です。そうですか？ systemd-networkdの場合は、DBusインターフェースを使用してntpクライアントを統合する必要があります。そうですか？
[*] 通常、ネットワーク接続がより簡単なためです。通常、グローバルインターネットとDNSへのアクティブな接続を持つ単一のルーターに直接接続できます。あるいは、ネットワークは内部的に複雑ですが、個々のコンポーネントの障害/回復頻度が低くなります。たとえば、通常、インターネット接続時間が50％のメッシュネットワークを使用しようとしません。
答え1
不拡散
ntpdNTPデーモンを参照してください。メッセージ全体if-up.dには、Debianのスクリプトフックのリストが含まれています。ntpd（または）フックスクリプトがありませんchrony。 NTP関連のスクリプトはntpdateとだけですopenntpd。
ntpdサーバーから応答が受信されない場合は、64秒後にパケットを再送信すると考えられます。
編集：ただし、再試行が何度も失敗すると、再試行間隔が長くなり、最終的に1024秒に達します。 (両方の値は設定可能ですが、デフォルト値です.)
文書ntpdはまた、「モデムの呼び出しが完了できるように」ある程度時間が選択されていると主張しています。これはntpd、明示的な通知なしに動的に確立されたネットワーク接続と切断されたネットワーク接続をサポートできるように設計されているようです。しかし、その部分は誤解を招くようです。上記の最大再試行間隔を考慮すると、デフォルト設定がすべての場合に適しているとは限りません。
慢性病患者
対照的に、その他参考資料ntp部分的には、DNSの問題によりダイヤルアップの使用には適していません。これはchronyよりうまく機能しますが、スクリプトフックを使用するように設計されています。 Fedora Linux 29のchrony-3.4パッケージにはフックスクリプトが含まれています/etc/NetworkManager/dispatcher.d/20-chrony。
システム時刻同期
systemd-timesyncdsystemd-networkd他と統合しないでください。現在、文書化されていないインターフェイスを使用しているようです。
systemd-timesyncdがオンラインだと思って「接続」できないようです。30秒ごとに再試行。
systemd-networkd最初はDBusインターフェイスがありませんでした。。あるいは、むしろそれが持っているものは考慮されません。準備するしかし。
セマンティクスを使用してフックスクリプトを実行することは可能ですsystemd-networkd。利用可能なセマンティクスの違いによって、if-up.dすべてのフックスクリプトを自動的に実行するのは良い考えではありません。 （質問にリンクされているDebianのバグスレッドに記載されているように）。望むより：
systemd-networkdを使用してネットワーク構成を変更するときのタスクの実行
[*] これはまた設計が古代ntpdに聞こえるようにするので可能現代的な考慮事項と完全に一致しません。たとえば、バッテリーで動作する小型タブレットデバイスの場合です。 [**] サーバーが応答しない場合は、64秒ごとに再試行しますか？ 編集：システムは64秒ごとに無期限に再試行しません。接続できない期間が経過すると、ポーリング間隔が長くなります。 （ "poll（）ルーチンには、サーバーに接続できない場合にポーリング間隔を短縮する機能が含まれています..."）
[**]私が理解しているように、「モバイル」クラスのデバイスは、ネットワークハードウェア（CPUを起動せずにARPに応答できる場合）を除いて、一晩滞在しながらほとんどのシステムを一時停止できるように設計されています。暗号化キー（WPAなど）を循環できます。