我有一个相当简单的设置，其中有两台计算机：
计算机 A. 具有正常的 NTP 设置，并使用标准 Internet 资源（根据 Ubuntu）来确定时间。它还允许查询 IP 10.0.2.0/24：
restrict 10.0.2.0 mask 255.255.255.0 nomodify notrap
计算机 B 具有正常的 NTP 设置，除了所有源都更改为使用10.0.2.1（即计算机 A）。
偶尔，计算机 A 会从其某个源收到死亡之吻信号。结果，它完全杀死了计算机 B 的 NTP（即，看起来像是直接传输了 KoD）。
有没有办法知道 NTP 服务器的状态，即它是否只会发送 KoD 消息？（此外，我该如何摆脱这种情况？当我查看它时，日志中显示的所有 IP 地址都未被服务器使用？！所以我不明白为什么它坚持将 KoD 发送给其客户端）。
到目前为止我发现了两件事：
ntpq我可以
ntpq像这样运行：ntpq -pn当 NTP 服务器工作时，我可以看到计算机满意的 IP 地址前面有一个星号。就我而言，所有状态标志（第一列
+、-、*、#等）都消失了。据我所知，这意味着 NTP 服务不正常，没有执行同步。下面是一个仍然有效的例子（即在第一列中有标志）：
remote refid st t when poll reach delay offset jitter ============================================================================== 10.0.2.255 .BCST. 16 B - 64 0 0.000 0.000 0.000 #51.77.203.211 134.59.1.5 3 u 4 64 1 171.248 -743.64 691.917 +72.5.72.15 216.218.254.202 2 u 2 64 1 19.223 -778.34 686.200 +159.69.25.180 192.53.103.103 2 u 3 64 1 237.733 -775.41 701.376 +173.0.48.220 43.77.130.254 2 u 2 64 1 35.489 -778.85 669.187 38.229.56.9 172.16.21.35 2 u 31 64 1 153.976 -268.90 122.557 +137.190.2.4 .PPS. 1 u 31 64 1 93.797 -253.69 116.289 +150.136.0.232 185.125.206.71 3 u 35 64 1 95.667 -178.19 114.912 94.154.96.7 194.29.130.252 2 u 31 64 1 237.560 -231.88 107.230 +162.159.200.123 10.4.1.175 3 u 34 64 1 16.246 -199.68 115.561 *216.218.254.202 .CDMA. 1 u 35 64 1 52.906 -193.84 131.148 91.189.91.157 132.163.96.1 2 u 45 64 1 87.772 -5.716 0.000 +204.2.134.163 44.24.199.34 3 u 34 64 1 16.711 -199.12 116.777 +74.6.168.73 208.71.46.33 2 u 35 64 1 69.772 -189.21 128.119 91.189.89.199 17.253.34.123 2 u 45 64 1 165.471 -3.708 0.000 +216.229.0.49 216.218.192.202 2 u 35 64 1 71.437 -178.94 97.505 91.189.89.198 17.253.34.123 2 u 44 64 1 172.852 -17.899 0.000ntpdate -q <ip>该
ntpdate命令实际上会告诉我 NTP 是否正在接受数据包。这是因为如果没有，它会给出错误消息：$ sudo ntpdate -q 10.0.2.1 server 10.0.2.1, stratum 4, offset 5.194725, delay 0.02652 21 Jul 15:22:48 ntpdate[13086]: no server suitable for synchronization found过了一会儿，当我的主服务器丢失了它
*最初乐意同步的那台服务器上的状态时，就会发生这种情况……
现在......我仍然需要了解我必须做什么来解决这个问题......
这可能会有所帮助，以下是有关从完全重启重新启动的日志：
Jul 21 18:29:13 vm-ve-ctl kernel: [ 434.275481] audit: type=1400 audit(1626917353.636:43): apparmor="DENIED" operation="open" profile="/usr/sbin/ntp
d" name="/snap/bin/" pid=3896 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jul 21 18:29:13 vm-ve-ctl ntpd[3896]: ntpd [email protected] (1): Starting
Jul 21 18:29:13 vm-ve-ctl ntpd[3896]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 126:129
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: proto: precision = 0.190 usec (-22)
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Cannot open logfile /var/log/ntp.log: Permission denied
Jul 21 18:29:13 vm-ve-ctl kernel: [ 434.291490] audit: type=1400 audit(1626917353.652:44): apparmor="DENIED" operation="capable" profile="/usr/sbin/
ntpd" pid=3901 comm="ntpd" capability=1 capname="dac_override"
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2021-12-28T00:00:00Z last=2017-01-01T
00:00:00Z ofs=37
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen and drop on 0 v6wildcard [::]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 2 lo 127.0.0.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 3 enp0s3 192.168.2.120:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 4 enp0s8 10.0.2.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 5 lo [::1]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 6 enp0s3 [fe80::a00:27ff:fe25:38ff%2]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 7 enp0s8 [fe80::a00:27ff:fe35:c30b%3]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listening on routing socket on fd #24 for interface updates
Jul 21 18:29:14 vm-ve-ctl ntpd[3901]: Soliciting pool server 51.77.203.211
Jul 21 18:29:15 vm-ve-ctl ntpd[3901]: Soliciting pool server 159.69.25.180
Jul 21 18:29:15 vm-ve-ctl ntpd[3901]: Soliciting pool server 72.5.72.15
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 198.251.86.68
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 173.0.48.220
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 38.229.56.9
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 150.136.0.232
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 94.154.96.7
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 137.190.2.4
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 162.159.200.123
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 216.218.254.202
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.91.157
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.89.199
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 74.6.168.73
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 204.2.134.163
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.89.198
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 216.229.0.49
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 2604:ed40:1000:1711:d862:f5ff:fe4e:41c4
Jul 21 18:29:21 vm-ve-ctl ntpd[3901]: receive: Unexpected origin timestamp 0xe4a34871.ac57f05d does not match aorg 0000000000.00000000 from [email protected] xmt 0xe4a34871.65648c54
我不知道它什么时候开始变坏。我还看到了下面的内容，我认为它可能与此有关（即当发生这种情况时，相应的 IP 将从列表中删除！），但现在它已经很糟糕了，上次运行中没有发生这样的错误。
Jul 21 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 local addr 192.168.2.120 -> <null>
注意：192.168.2.120 是故障计算机的 IP。它是 VirtualBox。它已经运行了几个月……不过，也许有些变化让它不高兴了。
我发现这个帖子关于消息的问题... -> <null>。不过，我认为我们在 Ubuntu 18.04 上有一个较新的版本：
SUSE最低推荐版本：ntp-4.2.8p7-11.1
Ubuntu 18.04版本：1:4.2.8p10+dfsg-5ubuntu7.3
以防万一，我尝试将虚拟机连接到主机，但仍然出现巨大的偏移和抖动。可能发生了什么变化？！
remote refid st t when poll reach delay offset jitter
==============================================================================
10.0.2.10 .POOL. 16 p - 64 0 0.000 0.000 0.000
10.0.2.10 132.163.97.6 2 u 54 64 3 0.457 -5254.2 3917.68
根据 Paul Gear 的要求，以下是 ntpq 的输出以及其他详细信息：
$ ntpq -ncrv
associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
version="ntpd [email protected] (1)", processor="x86_64",
system="Linux/4.15.0-151-generic", leap=00, stratum=4, precision=-23,
rootdelay=17.930, rootdisp=5019.260, refid=173.255.215.209,
reftime=e4a44f7a.1c2ec778 Thu, Jul 22 2021 13:11:38.110,
clock=e4a45030.c8a4b259 Thu, Jul 22 2021 13:14:40.783, peer=0, tc=6,
mintc=3, offset=-109.527915, frequency=-1.707, sys_jitter=0.000000,
clk_jitter=38.724, clk_wander=0.000, tai=37, leapsec=201701010000,
expire=202112280000
以下是可用时钟和当前使用的时钟的列表：
$ grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:kvm-clock tsc acpi_pm
/sys/devices/system/clocksource/clocksource0/current_clocksource:kvm-clock
最后，dmesg关于时钟源选择过程的输出：
$ dmesg | grep clocksource
[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.283117] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 1.161844] clocksource: Switched to clocksource kvm-clock
[ 1.208316] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 2.329228] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1db81a3240f, max_idle_ns: 440795250379 ns
答案1
看来我找到了解决办法。不过我不太清楚为什么以前它会起作用。
经过多次搜索，我找到了这个 VirtualBox 票证：
https://www.virtualbox.org/ticket/15179
这意味着你不应该使用，ntpd因为虚拟机已经使用主机时间来调整虚拟机的虚拟时钟。
但是，即使没有ntpd运行，我的虚拟机的时钟也会关闭，并且会在短时间内在 ±30 秒之间波动。
进一步阅读该帖子后，他们建议将半虚拟化设置调整为“无”。这似乎对我不起作用。我重新启动了虚拟机，但它卡住了。所以我尝试使用“最小”，现在时钟可以正常工作了。输出ntpq -np看起来好多了：
Thu Jul 22 12:57:57 PDT 2021
remote refid st t when poll reach delay offset jitter
==============================================================================
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.008
+23.157.160.168 129.6.15.28 2 u 20 128 377 83.831 0.783 1.745
-104.131.139.195 163.237.218.19 2 u 28 128 377 20.162 3.622 1.451
+144.76.64.40 36.224.68.195 2 u 18 128 377 179.329 2.557 6.671
-159.89.86.140 192.5.41.40 2 u 126 128 377 87.016 3.094 1.385
-23.175.208.10 239.9.71.195 2 u 35 128 377 82.350 2.311 0.794
+206.82.16.3 47.187.174.51 2 u 127 128 377 84.683 1.385 0.753
+92.243.6.5 85.199.214.98 2 u 25 128 377 163.041 4.275 4.025
*200.160.7.186 .ONBR. 1 u 47 128 377 191.078 1.126 1.865
+51.255.197.148 217.91.44.17 2 u 96 128 367 154.201 1.225 4.742
我们可以看到，与我之前得到的相比，偏移量（最大 4.3）和抖动（最大 6.7）微不足道。现在我的另一台电脑也可以正常工作，并且可以与这个时钟同步。延迟大约为 0.7，这对我来说已经足够了（在我的情况下，12.0 或更少就足够了）。
重要的提示：我使用以下命令重启了虚拟机 2 到 3 次最小，启动时间非常长。因此，除非您绝对需要一个正常工作的系统时钟，否则我不建议使用此模式。如果您有更好的解决方案，我愿意倾听！
为了以防万一，我想看看时钟源方面的差异最小模式。我们只获取acpi_pm时钟。
$ grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:acpi_pm
/sys/devices/system/clocksource/clocksource0/current_clocksource:acpi_pm
现在我想知道这是否会影响主机时钟。由于我的主机上也有 ntp，所以我认为这不是问题。
答案2
好吧，这很不寻常，我添加了第二个答案，因为这 100% 解释了为什么开始出现问题。在我上次重新启动后的几天内，有一个 NVidia 驱动程序升级。然后我启动了我的虚拟机（也就是说，这里的顺序非常重要！）
我不知道 3D 环境可能会丢失，如果不加速，那么 VM 在时钟/时间方面会完全出现错误。
请注意，我没有注意到 3D 环境不可用。一些日志中可能提到了这一点，但作为标准用户，我完全错过了那部分。
完全重启后（NVidia 升级需要），虚拟机可以再次正常工作。无需使用最小选项。我把那个虚拟机放回默认并且它仍然像以前一样运行良好。
我希望这可以帮助一些人免去我三天来的头疼...
对于那些感兴趣的人，更改时钟也可能有帮助。Oracle 有一个关于如何更改时钟源。就我而言，我最终使用了，apci_pm这似乎对长时间保持时间有很大帮助。
# echo "acpi_pm" > /sys/devices/system/clocksource/clocksource0/current_clocksource
您还可以更新您的启动参数，这样每次启动时您都可以获得所选的源。
GRUB_CMDLINE_LINUX="... clocksource=acpi_pm"
（这里我删除了不相关的参数，不要删除它们，只需添加参数clocksource；也可能是第一次编辑时变量为空：）GRUB_CMDLINE_LINUX=""。