VirtualBox Linux 伺服器中的 NTP 同步故障排除
我有一個相當簡單的設置，我有兩台電腦：
電腦 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.000
ntpdate -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 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 -> <null>注意：192.168.2.120 是故障電腦的 IP。它是一個虛擬盒子。它已經工作了幾個月……不過，也許發生了一些變化，這讓它不開心。
我發現這篇關於消息問題的
... -> <null>文章。但是，我認為我們在 Ubuntu 18.04 上有一個更新的版本：SUSE 最低推薦版本：
ntp-4.2.8p7-11.1Ubuntu 18.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 Gear 所問的，這裡是 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
好的，相當不尋常，我要添加第二個答案，因為這 100% 解釋了為什麼開始中斷。在我上次重新啟動後的幾天內，有一個 NVidia 驅動程序升級。然後我啟動了我的虛擬機（即這裡的順序非常重要！）
我不知道 3D 環境可能會失去，如果不加速，那麼 VM 在時鐘/時間方面將完全不正常。
請注意，我看不到 3D 環境不可用的事實。可能在一些日誌中提到過，但作為一個標準使用者，我完全錯過了那部分。
完全重新啟動後（該 NVidia 升級需要），VM 再次正常工作。無需使用最小選項。我將該虛擬機恢復為預設值，它和以前一樣一直執行良好。
我希望這可以避免一些人頭痛 3 天…
對於那些感興趣的人，更改時鐘也可能有所幫助。Oracle 有一個關於如何更改時鐘源的好頁面。最後，我最終使用了
apci_pm似乎有助於長時間保持時間的方法。# echo "acpi_pm" > /sys/devices/system/clocksource/clocksource0/current_clocksource您還可以更新您的啟動參數，以便每次啟動時都能獲得所選的源。
GRUB_CMDLINE_LINUX="... clocksource=acpi_pm"（我這裡去掉了不相關的參數，不要刪除，直接加
clocksource參數即可；也有可能是第一次編輯時變數為空：）GRUB_CMDLINE_LINUX=""。
看來我找到了解決方案。不過，我不太確定為什麼它以前會起作用。
經過多次搜尋，我找到了這張 VirtualBox 票：
https://www.virtualbox.org/ticket/15179
這表示您不應該使用
ntpd，因為虛擬機已經使用主機時間來調整虛擬機的虛擬時鐘。但是，即使沒有
ntpd執行，我的虛擬機的時鐘也會關閉，並且會在短時間內在 ±30 秒之間跳動。進一步閱讀該文章，他們提出將半虛擬化設置調整為“無”。這似乎對我不起作用。我重新啟動了虛擬機，它卡住了。所以我改為嘗試使用“Minimal”，現在時鍾正在工作。
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 或更少）。
重要提示：我使用****Minimal重新啟動了 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，我認為這不是問題。