VirtualBox Linux服务器中NTP同步的故障排除

Question

我有一个相当简单的设置，其中我有两台计算机：

计算机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发送给它的客户)。

到目前为止，我发现了两件事：

1. ntpq我可以像这样运行ntpq：ntpq -pn，当NTP服务器工作时，我可以在计算机满意的IP地址前面看到一个星号。在我的例子中，所有的状态标志(第一列+、-、*、#等)都消失了。据我所知，这意味着NTP服务不愉快，并且没有执行同步。下面是一个仍然有效的示例(即在第一列中有标志)：当轮询到达延迟偏移抖动============================================================================== 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.180 192.53.103 2 u 3 64 1 237.733 -775.41 +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 +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 641 87.772 -5.716 +204.2.134.163 44.199.34 3 u 34 64 1 16.711 -199.12 116.777 +74.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 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.000
2. ntpdate -q ntpdate命令实际上会告诉我NTP是否接受数据包。这是因为它给出了一个错误消息，如果不是：$ suitable -q 10.0.2.1服务器10.0.2.1，第4层，偏移5.194725，延迟0.02652 21，7月15:22:48 ntpdate:没有适合同步的服务器发现，当我的主服务器在一台服务器上丢失*状态时，它首先乐于与.

现在..。我还需要明白我要做些什么来解决这个问题.

这可能会有帮助，下面是关于从完全重新启动重新启动的日志：

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 4.2.8p10@1.3728-o (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 server@94.154.96.7 xmt 0xe4a34871.65648c54

我不知道它是什么时候开始变坏的。我还看到了我认为可能与之有关的以下内容(即，当发生这种情况时，相应的IP将从列表中删除！)，但现在它已经坏了，并且在我上次运行时没有发生这样的错误。

Jul 21 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 local addr 192.168.2.120 -> 

注: 192.168.2.120是故障计算机的IP。这是一个VirtualBox。已经用了好几个月了..。不过，也许是什么改变了让它不开心。

我发现了这个职位关于... -> 消息的一个问题。然而，我认为我们在Ubuntu18.04上有一个更新的版本：

SUSE最低推荐版本：ntp-4.2.8p7-11.1 Ubuntu18.04版本：1:4.2.8p10+dfsg-5ubuntu7.3

以防万一，我试图将VM连接到主机上，但仍然得到了巨大的偏移量和抖动。什么能改变？！

     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所问的，下面是ntpq的输出，并提供了其他详细信息：

$ ntpq -ncrv
associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
version="ntpd 4.2.8p10@1.3728-o (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

Answer 1

好吧，非常不寻常，我加入了第二个答案，因为这100%解释了为什么开始崩溃。在我上次重新启动之后的几天内，有一个NVidia驱动程序升级。然后我启动了VM (也就是说，订单在这里非常重要！)

我不知道3D环境可能会丢失，如果没有加速，那么VM就会在时钟/时间方面完全错误。

请注意，3D环境不可用的事实对我来说是不可见的。它可能在一些日志中提到过，但是作为一个标准用户，我完全忽略了这个部分。

在完全重新启动( NVidia升级所需的)之后，VM再次正常工作。不需要使用最小选项。我把这个VM放回了默认的，它和以前一样工作得很好。

我希望这能帮几个人省下3天的头痛.

对那些有兴趣的人来说，改变时钟也可能有帮助。甲骨文有一个很好的关于如何更改时钟源的页面。最后，我使用了apci_pm，这似乎极大地帮助了长时间的维护。

# echo "acpi_pm" > /sys/devices/system/clocksource/clocksource0/current_clocksource

您还可以更新您的引导参数，这样每次启动时都会得到所选的源代码。

GRUB_CMDLINE_LINUX="... clocksource=acpi_pm"

(我在这里删除了不相关的参数，不要删除它们，只需添加clocksource参数；当您第一次编辑变量：GRUB_CMDLINE_LINUX=""时，变量也可能是空的)。

Answer 2

看来我找到了解决办法。不过，我不太清楚为什么它以前会起作用。

经过多次搜索，我找到了这张VirtualBox票证：

https://www.virtualbox.org/ticket/15179

这意味着您不应该使用ntpd，因为VM已经占用了时间，使用主机时间来调整VM的虚拟时钟。

然而，即使在运行ntpd时，我的VM时钟也是关闭的，在短时间内会在±30秒之间反弹。

进一步阅读这篇文章，他们提出将半虚拟化设置调整为“无”。这对我来说似乎不管用。我重新启动了VM，它被卡住了。所以我试着用“最小”的方法，现在时钟开始工作了。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或更少)。

IMPORTANT注意：我重新启动了VM 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，所以我不认为这是个问题。