☰

NTP 客户端是否可以动态检测何时尝试连接到服务器，而不与特定的网络配置系统集成？

tag-icon • tag-icon dns ntp systemd-networkd
NTP 客户端是否可以动态检测何时尝试连接到服务器，而不与特定的网络配置系统集成？

ntpd 可以很好地处理动态网络配置，timesyncd 也是如此；日期绝不处理动态网络配置，我认为当真正的 NTP 守护进程自动执行正确的操作时，使用脚本来解决这个问题是没有意义的。 ntpdate（以及其他软件，如 tlsdate）作为独立工具是有意义的，但自动调用它似乎不太明智。 （此外，持续保持时间最新更有意义，而不是仅在启动或网络更改时更新。）

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798625#13

我至少理解这个论点的一部分。现代 PC 通过运行轻量级守护程序来保持时钟准确是合理的。

假设网络配置是动态的，并且NTP守护进程没有与特定的网络配置系统集成。它仅使用通用接口（包括一些Linux内核接口）。要完成这项工作需要什么？

从历史上看，通过让网络系统运行脚本来专门集成是很常见的。但我搜索了一下，我认为systemd-networkd没有实现任何脚本挂钩。如果您查看上面的链接，它至少表明开发人员不太喜欢脚本挂钩。

这个问题有点假设 - 我心里有一个类似的问题，所以我想知道 NTP 是如何处理这个问题的。

如果判断最初同步 NTP 的尝试失败，我假设采用简单的方法，例如一小时后重试就足够了。[*]

a) 我的问题是你如何检测何时应该尝试开始。我认为这可能会有所不同，具体取决于您配置 NTP 客户端使用的服务器。例如

  1. DNS 服务器已经配置了吗？
  2. 我们是否已配置到任何 DNS 服务器的路由？ （默认路由很好，但不一定在所有情况下都可用）。
  3. 是 DNS 服务器吗对于这个接口已配置且可访问吗？ （例如，当在多个接口上使用 systemd-networkd 对非全局 DNS 名称的支持时）。
  4. NTP 服务器主机名是否在不使用 DNS 服务器的情况下解析，例如使用 /etc/hosts 或 MDNS？
  5. 我们是否已配置到 NTP 服务器的路由？

b) 我们应该对pool.ntp.org服务器礼貌一点。所以我想我们不想在每个可能的网络配置事件之后立即重试？

c) 为了检测systemd-resolved（或 NetworkManager+dnsmasq，或...）何时配置了 DNS 服务器，您需要与该网络配置系统进行特定集成，对吧？对于 systemd-networkd，ntp 客户端必须使用 DBus 接口进行集成，对吧？

[*] 因为网络连接通常比较简单。您可以直接连接到单个路由器，该路由器通常具有与全球互联网和 DNS 的有效连接。或者网络内部更复杂，但各个组件不会经常发生故障/恢复。例如，通常我们不会尝试使用仅 50% 的时间具有互联网连接的网状网络。

答案1

不扩散

引用中提到ntpd，参考 NTP 守护进程。完整消息包括if-up.dDebian 中的脚本挂钩列表。 ntpd(nor )没有钩子脚本chrony。唯一与 NTP 相关的脚本是ntpdate和openntpd。

如果ntpd没有收到服务器的响应，我相信它会在 64 秒后重新发送数据包。

重试无响应 NTP 服务器的最小间隔是多少？

编辑：但是在多次重试失败后，重试间隔将增加，最终达到 1024 秒。 （这两个值都是可配置的，但这些是默认值）。

该ntpd文档还声称选择了一些时间“以允许调制解调器呼叫完成”。这听起来像是ntpd已经设计好的，因此它可以支持动态建立和丢失的网络连接，而无需明确通知。然而，相关部分似乎具有误导性。考虑到上面的最大重试间隔，我认为默认设置并不适用于所有可能的情况。

慢性的

相比之下，其他参考资料suggestntp不太适合拨号使用，部分原因是 DNS 问题。这chrony效果更好，但它被设计为使用脚本挂钩。 Fedora Linux 29 中的 chrony-3.4 软件包包含一个钩子脚本/etc/NetworkManager/dispatcher.d/20-chrony.

systemd-时间同步

systemd-timesyncdsystemd-networkd与（而不是其他）集成。目前它似乎使用了一个未记录的接口。

当 systemd-timesyncd 认为它在线并且无法“连接”时，它似乎每 30 秒重试一次。

systemd-networkd最初没有DBus接口。或者更确切地说，它所拥有的那个并不被认为是准备好然而。

使用语义运行钩子脚本似乎已经成为可能systemd-networkd。尽管if-up.d由于可用语义存在一些差异，自动运行所有挂钩脚本并不是一个好主意。 （正如问题中链接的 Debian bug 线程中所述）。看：

使用 systemd-networkd，在网络配置更改时执行操作

[*] 这也使得它的设计听起来像是ntpd古老的，所以它可能不完全符合现代考虑。例如，用于小型电池供电的平板设备。[**] 当服务器没有响应时，您是否希望每 64 秒重试一次？ 编辑：系统不会无限期地每 64 秒重试一次。经过一段时间的不可达后，轮询间隔会增加。 （“poll() 例程包含一个功能，如果服务器无法访问，则可以缩短轮询间隔......”）

[**] 据我了解，“移动”级设备的设计使得它们可以过夜并暂停大部分系统，但网络硬件可能除外（它可以在不唤醒 CPU 的情况下响应 ARP；也许它可以轮换加密密钥（例如 WPA）。

相关内容