当我查询 NTP 守护进程的状态时，ntpdc -c sysinfo我得到以下输出：
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -20
root distance: 0.00000 s
root dispersion: 12.77106 s
reference ID: [73.78.73.84]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
这表示 NTP 同步失败。但是系统时间精确到 1 秒精度。当我在没有网络连接的情况下运行我的系统时，系统时间会偏离大约 10 秒。
这种行为表明系统有另一种同步时间的方式。我意识到还有systemd-timesyncd.service（配置文件位于/etc/systemd/timesyncd.conf）并timedatectl status给了我正确的时间：
Local time: Thu 2016-08-25 10:55:23 CEST …我正在研究一些Beagle Bone Black (BBB)板上的一个非常奇怪的效果。我们看到系统时钟偶尔会出现几个月的跳跃，这总是与systemd-timesyncd更新系统时钟相关。我们每周会在不同地点的 2000 台设备中看到其中的 2 到 3 个。
我们花了很多时间检查 SNTP，但这似乎表现正常。
我们终于提出了板载实时时钟的硬件问题，由于电子噪声，该问题可能导致其随机跳跃 131072 秒（36 小时）。这并不立即正确，报告的时间跳跃非常具体并且比我们观察到的要少得多，但是对该问题的深入阅读表明跳跃可能更加随机，甚至可能倒退。
我的问题是... linux 如何使用实时时钟来维护系统时钟？
我想知道实时时钟的错误是否只会在时间同步代理（ntpd 或 systemd-timesyncd）更新时出现在系统时钟中。系统时钟和 RTC 之间是否有任何直接联系，还是仅由代理使用？
注意：在第一段中我提到我们在系统时钟中看到几个月的跳跃，这总是与systemd-timesyncd更新系统时钟相关。我的意思是，时间跳转后的第一个系统日志消息是一条Time has been changed系统日志消息：
grep 'Time has been changed' /var/log/syslog
Oct 2 23:53:33 hostname systemd[1]: Time has been changed
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
Nov 21 00:05:17 hostname systemd[1]: Time has been changed
Nov 21 00:03:29 hostname systemd[1]: Time has …我已经用它systemd-timesyncd作为我的系统计时器好几年了。我为我的 Raspberry Pi 运行一个名为raspbian的 Debian衍生产品。我对 SNTP 客户端非常满意，但想尝试在离网应用程序中使用。systemd-timesyncdchronyd
以下命令可用于列出配置systemd-timesyncd：
$ systemctl cat systemd-timesyncd
在buster中，此清单中有一段代码，systemd-timesyncd如果发现安装了另一个计时服务（NTP守护进程），则可以“原谅自己”：
# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService
在buster发布后的某个时刻（与bullseye同时发布？？），上述方案被更改；如果发现其他计时器，该命令不再包含任何限制或禁止启动的引用。systemctl cat systemd-timesyncdsystemd-timesyncd
有谁还记得这个变化的历史吗？更重要的是，systemd-timesyncd如果发现安装了另一个计时守护进程，是否仍然会抑制其启动？这是在哪里/如何完成的？
在同一台机器上systemd-timesyncd运行有什么问题吗？ntp
我问这个是因为我已经开始NTP在所有服务器上使用，但它systemd-timesyncd也在那里运行。我应该禁用它吗？两者运行有问题吗？
我正在尝试在 Archlinux 上启动 systemd-timesyncd，它是通过 Distrod 安装在 WSL 之上的。默认情况下，systemd-timesyncd 的单元文件会阻止它在虚拟化环境中启动，该单元文件有一个ConditionVirtualization=!container标志。我正在尝试使用以下配置来覆盖它：
[root@valentine ~]# systemd-detect-virt\nwsl\n[root@valentine ~]# cat /etc/systemd/system/systemd-timesyncd.service.d/override.conf\n[Unit]\nConditionVirtualization=wsl\n[root@valentine ~]# systemctl daemon-reload\n[root@valentine ~]# systemctl start systemd-timesyncd.service\n[root@valentine ~]# systemctl status systemd-timesyncd.service\n\xe2\x97\x8b systemd-timesyncd.service - Network Time Synchronization\n Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)\n Drop-In: /etc/systemd/system/systemd-timesyncd.service.d\n \xe2\x94\x94\xe2\x94\x80override.conf\n Active: inactive (dead)\n Condition: start condition failed at Mon 2023-02-27 10:38:46 CET; 6s ago\n \xe2\x94\x94\xe2\x94\x80 ConditionVirtualization=!container was not met\n Docs: man:systemd-timesyncd.service(8)\n\nFeb 27 10:38:46 valentine systemd[1]: Network Time Synchronization was skipped because of an unmet condition check (ConditionVirtualization=!container).\n …arch-linux systemd windows-subsystem-for-linux systemd-timesyncd