У меня довольно простая установка, где у меня есть два компьютера:
Компьютер A. имеет обычную настройку NTP и использует стандартные интернет-источники (согласно Ubuntu) для определения времени. Он также позволяет запрашивать IP 10.0.2.0/24:
ограничить 10.0.2.0 маска 255.255.255.0 nomodify notrap
Компьютер B. имеет обычную настройку NTP, за исключением того, что все источники изменены для использования 10.0.2.1 (это компьютер А).
Время от времени компьютер А получает сигнал «Поцелуй смерти» от одного из своих источников. В результате он полностью убивает NTP компьютера B (т. е. похоже, что KoD передается напрямую).
Есть ли способ узнать состояние сервера NTP с точки зрения того, будет ли он просто отправлять сообщение KoD или нет? (также, как мне выйти из этой ситуации? Когда я посмотрел на это, все IP-адреса, показанные в журнале, не использовались сервером?! поэтому я не понимаю, почему он настаивает на отправке KoD своему клиенту) .
Пока нашел две вещи:
нтпк
я могу бежать нтпк вот так:
нтпк-пн
Когда сервер NTP работает, я вижу звездочку перед IP-адресом, которым доволен компьютер. В моем случае все флаги состояния (первый столбец +, -, *, #и т.д.) все исчезает. Насколько я знаю, это означает, что служба NTP не работает и синхронизация не выполняется.
Вот пример, когда он еще работает (т.е. есть флаги в самом первом столбце):
удаленный refid st t при достижении опроса джиттер смещения задержки
================================================== =============================
10.0.2.255 .BCST. 16 Б - 64 0 0,000 0,000 0,000
#51.77.203.211 134.59.1.5 3 и 4 64 1 171.248 -743.64 691.917
+72.5.72.15 216.218.254.202 2 и 2 64 1 19.223 -778.34 686.200
+159.69.25.180 192.53.103.103 2 и 3 64 1 237.733 -775.41 701.376
+173.0.48.220 43.77.130.254 2 и 2 64 1 35.489 -778.85 669.187
38.229.56.9 172.16.21.35 2 и 31 64 1 153.976 -268.90 122.557
+137.190.2.4 .ППС. 1 и 31 64 1 93,797 -253,69 116,289
+150.136.0.232 185.125.206.71 3 и 35 64 1 95.667 -178.19 114.912
94.154.96.7 194.29.130.252 2 и 31 64 1 237.560 -231.88 107.230
+162.159.200.123 10.4.1.175 3 и 34 64 1 16.246 -199.68 115.561
*216.218.254.202 .CDMA. 1 ед 35 64 1 52,906 -193,84 131,148
91.189.91.157 132.163.96.1 2 и 45 64 1 87.772 -5.716 0.000
+204.2.134.163 44.24.199.34 3 и 34 64 1 16.711 -199.12 116.777
+74.6.168.73 208.71.46.33 2 и 35 64 1 69.772 -189.21 128.119
91.189.89.199 17.253.34.123 2 и 45 64 1 165.471 -3.708 0.000
+216.229.0.49 216.218.192.202 2 и 35 64 1 71.437 -178.94 97.505
91.189.89.198 17.253.34.123 2 и 44 64 1 172.852 -17.899 0.000
ntpdate -q <ip>
нтпдате команда на самом деле скажет мне, принимает ли NTP пакеты. Это потому, что он выдает сообщение об ошибке, если нет:
$ судо ntpdate -q 10.0.2.1
сервер 10.0.2.1, слой 4, смещение 5.194725, задержка 0.02652
21 июл, 15:22:48 ntpdate[13086]: сервер, пригодный для синхронизации, не найден
Это происходит через некоторое время, когда мой основной сервер теряет * статус на одном сервере, с которым сначала было приятно синхронизироваться...
Теперь... Мне все еще нужно понять, что я должен сделать, чтобы решить эту проблему...
Это может быть полезно, вот логи о перезапуске после полной перезагрузки:
21 июля, 18:29:13 ядро vm-ve-ctl: [434.275481] аудит: тип = 1400 аудит (1626917353.636:43): apparmor = "ОТКЛОНЕН" операция = "открыть" профиль = "/usr/sbin/ntp
d" name="/snap/bin/" pid=3896 comm="ntpd" required_mask="r" disabled_mask="r" fsuid=0 ouid=0
21 июля 18:29:13 vm-ve-ctl ntpd[3896]: ntpd [email protected] (1): запуск
21 июля, 18:29:13 vm-ve-ctl ntpd[3896]: Командная строка: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 126:129
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: прототип: точность = 0,190 мкс (-22)
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: невозможно открыть файл журнала /var/log/ntp.log: в доступе отказано
21 июля, 18:29:13 ядро vm-ve-ctl: [434.291490] аудит: тип = 1400 аудит (1626917353.652:44): apparmor = "ОТКЛОНЕН" операция = "способный" профиль = "/usr/sbin/
ntpd" pid=3901 comm="ntpd" возможность=1 capname="dac_override"
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: файл дополнительной секунды ('/usr/share/zoneinfo/leap-seconds.list'): хорошая хэш-подпись
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: файл дополнительной секунды ('/usr/share/zoneinfo/leap-seconds.list'): загружен, срок действия = 2021-12-28T00:00:00Z последний =2017-01-01T
00:00:00Z ofs=37
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: Прослушайте и перетащите на 0 v6wildcard [::]:123
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: прослушайте и перетащите на 1 v4wildcard 0.0.0.0:123
21 июля, 18:29:13.
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: нормально слушать на 3 enp0s3 192.168.2.120:123
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: нормально слушать на 4 enp0s8 10.0.2.1:123
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: нормально слушать на 5 lo [::1]:123
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: нормально слушать на 6 enp0s3 [fe80::a00:27ff:fe25:38ff%2]:123
21 июля, 18:29:13 vm-ve-ctl ntpd[3901]: нормально слушать на 7 enp0s8 [fe80::a00:27ff:fe35:c30b%3]:123
21 июля, 18:29:13 vm-ve-ctl ntpd [3901]: прослушивание сокета маршрутизации на fd # 24 для обновлений интерфейса
21 июля, 18:29:14 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 51.77.203.211
21 июля, 18:29:15 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 159.69.25.180
21 июля, 18:29:15 vm-ve-ctl ntpd[3901]: Запрос сервера пула 72.5.72.15
21 июля, 18:29:16 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 198.251.86.68
21 июля, 18:29:16 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 173.0.48.220
21 июля, 18:29:16 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 38.229.56.9
21 июля, 18:29:17 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 150.136.0.232.
21 июля, 18:29:17 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 94.154.96.7
21 июля, 18:29:17 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 137.190.2.4
21 июля, 18:29:18 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 162.159.200.123
21 июля, 18:29:18 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 216.218.254.202
21 июля, 18:29:18 vm-ve-ctl ntpd[3901]: Запрос сервера пула 91.189.91.157
21 июля, 18:29:19 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 91.189.89.199
21 июля, 18:29:19 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 74.6.168.73
21 июля, 18:29:19 vm-ve-ctl ntpd[3901]: Запрос сервера пула 204.2.134.163
21 июля, 18:29:20 vm-ve-ctl ntpd[3901]: запрашивается сервер пула 91.189.89.198.
21 июля, 18:29:20 vm-ve-ctl ntpd[3901]: Запрос сервера пула 216.229.0.49
21 июля, 18:29:20 vm-ve-ctl ntpd[3901]: запрос сервера пула 2604:ed40:1000:1711:d862:f5ff:fe4e:41c4
21 июля, 18:29:21.
Я не знаю точно, когда это начинает портиться. Я также видел следующее, что, как я думал, может иметь какое-то отношение к этому (т.е. когда это происходит, соответствующий IP-адрес удаляется из списка!), но это уже плохо, и в моем последнем запуске такой ошибки не было.
21 июля 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 локальный адрес 192.168.2.120 -> <null>
Примечание. 192.168.2.120 — это IP-адрес неисправного компьютера. Это виртуальный бокс. Он работает уже несколько месяцев... хотя, возможно, что-то изменилось, что делает его несчастным.
я нашел эта почта о проблеме с ... -> <нуль> сообщение. Однако я думаю, что у нас есть более новая версия Ubuntu 18.04:
Минимальная рекомендуемая версия SUSE: нтп-4.2.8p7-11.1
Версия Ubuntu 18.04: 1:4.2.8p10+dfsg-5ubuntu7.3
На всякий случай я попытался подключить виртуальную машину к хосту, но все равно получаю огромное смещение и дрожание. Что могло измениться?!
удаленный refid st t при достижении опроса джиттер смещения задержки
================================================== =============================
10.0.2.10 .БАССЕЙН. 16 р - 64 0 0,000 0,000 0,000
10.0.2.10 132.163.97.6 2 и 54 64 3 0,457 -5254,2 3917,68
По просьбе Пола Гир, вот вывод ntpq с дополнительной информацией:
$ntpq -ncrv
associd=0 status=0028 jump_none, sync_unspec, 2 события, no_sys_peer,
версия = "ntpd [email protected] (1)", процессор = "x86_64",
system="Linux/4.15.0-151-generic", скачок=00, уровень=4, точность=-23,
rootdelay=17.930, rootdisp=5019.260, refid=173.255.215.209,
reftime=e4a44f7a.1c2ec778 Чт, 22 июля 2021 г., 13:11:38.110,
clock=e4a45030.c8a4b259 Чт, 22 июля 2021 г., 13:14:40.783, peer=0, tc=6,
mintc=3, смещение=-109,527915, частота=-1,707, sys_jitter=0,000000,
clk_jitter=38,724, clk_wander=0,000, tai=37, jumpsec=201701010000,
срок действия = 202112280000
Вот список доступных часов и тот, который используется в настоящее время:
$грэп. /sys/devices/system/источник часов/источник часов*/[ac]*источник часов
/sys/devices/system/clocksource/clocksource0/available_clocksource:kvm-часы tsc acpi_pm
/sys/devices/system/clocksource/clocksource0/current_clocksource:kvm-часы
И, наконец, dmesg вывод о процессе выбора источника синхронизации:
$ dmesg | источник синхронизации grep
[0.000000] источник часов: kvm-часы: маска: 0xffffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 нс
[ 0.000000] источник часов: уточненный-jiffies: маска: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 нс
[ 0.283117] источник часов: jiffies: маска: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 нс
[ 1.161844] источник часов: переключен на источник часов kvm-clock
[1.208316] источник часов: acpi_pm: маска: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 нс
[ 2.329228] источник часов: tsc: маска: 0xffffffffffffffffff max_cycles: 0x1db81a3240f, max_idle_ns: 440795250379 нс
