У меня довольно простая установка, где у меня есть два компьютера:
Компьютер A. имеет обычную настройку NTP и использует стандартные Интернет-источники (согласно Ubuntu) для определить время. Он также позволяет выполнять запросы по IP 10.0.2.0/24
:
restrict 10.0.2.0 mask 255.255.255.0 nomodify notrap
Компьютер Б. имеет обычную настройку NTP, за исключением того, что все источники изменены на использование 10.0.2.1
( что компьютер A).
Время от времени Компьютер A получает сигнал «Поцелуй смерти» от одного из его источников. В результате он полностью убивает NTP компьютера B (т.е.похоже KoD передается напрямую).
Есть ли способ узнать состояние сервера NTP с точки зрения того, будет ли он просто отправлять сообщение KoD или нет? (также, как мне выйти из этой ситуации? Когда я посмотрел на него, весь IP-адрес, указанный в журнале, не использовался сервером ?! поэтому я не понимаю, почему он настаивает на отправке KoD своему клиенту) .
Я обнаружил две вещи:
ntpq
Я могу запустить ntpq
следующим образом:
ntpq -pn
Когда сервер NTP работает, я вижу звездочку перед IP-адресом компьютера. В моем случае все флаги состояния (первый столбец +
, -
, *
, #
и т. Д.) Исчезают. Насколько мне известно, это означает, что служба NTP недовольна и синхронизация не выполняется.
Вот пример, когда он все еще работает (т.е. есть флаги в самом первом столбце):
remote refid st t, когда опрос достигает дрожания смещения задержки
========= ================================================== ===================
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
Команда ntpdate
фактически сообщит мне, принимает ли NTP пакеты. Это потому, что в противном случае выдается сообщение об ошибке:
$ sudo ntpdate -q 10.0.2.1
сервер 10.0.2.1, слой 4, смещение 5.194725, задержка 0,02652
21 июля, 15:22 : 48 ntpdate [13086]: сервер, подходящий для синхронизации, не найден
Это происходит через некоторое время, когда мой главный сервер теряет статус *
на одном сервере, которому он был сначала рад синхронизировать с ...
Теперь ... Мне все еще нужно понять, что мне нужно сделать, чтобы исправить эту проблему ...
Это может быть полезно, вот журналы о перезапуске после полной перезагрузки:
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-адрес отказавшего компьютера. Это VirtualBox. Он работает уже несколько месяцев ... хотя, возможно, что-то изменилось, что делает его несчастным.
Я нашел это сообщение о проблеме с сообщением ... ->
. Однако я думаю, что у нас есть более новая версия 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
По просьбе Пола Гира, вот результат 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
Okay, ziemlich ungewöhnlich, ich füge eine zweite Antwort hinzu, weil diese 100% erklärt, warum die zu brechen begann. Innerhalb weniger Tage nach dem letzten Neustart gibt es ein NVidia-Treiber-Upgrade. Dann habe ich meine VM gestartet (d.h. die Reihenfolge ist hier sehr wichtig!)
Ich wusste nicht, dass die 3D-Umgebung fehlen könnte und wenn nicht beschleunigt, dann würde sich die VM in Bezug auf Uhr / Zeit völlig falsch verhalten.
Beachten Sie, dass die Tatsache, dass die 3D-Umgebung nicht verfügbar ist, für mich nicht sichtbar war.Возможно, он упоминался в некоторых журналах, но как пользователь standard я полностью пропустил эту часть.
После полной перезагрузки (требуемой обновлением NVidia) виртуальная машина снова работает нормально. Нет необходимости использовать опцию Minimal. Я вернул эту виртуальную машину в Default, и она хорошо работает, как и раньше.
Я надеюсь, что это спасет нескольких человек от головного уклада, который у меня был в течение 3 дней...
Похоже, я нашел решение. Однако я не совсем уверен, почему это могло работать раньше.
После многих поисков я нашел этот билет VirtualBox:
https://www.virtualbox.org/ticket/15179
, в котором говорится, что вам не следует использовать ntpd
, потому что виртуальная машина уже отслеживает время, используя время хоста для настройки виртуальных часов виртуальной машины .
Однако даже без запущенного h 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 раза, используя Minimal , время загрузки мучительно велико. Поэтому я не рекомендую использовать этот режим, кроме как в самом крайнем случае, если вам абсолютно необходимы рабочие системные часы. Если у вас есть лучшее решение, которое работает, я весь в ушах!
На всякий случай, я хотел увидеть разницу в отношении источников синхронизации в режиме Minimal . Мы просто получаем часы 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 на моем хосте, я не думаю, что это проблема.