Am o configurare destul de simplă în care am două computere:
Computerul A. are o configurare normală NTP și utilizează sursele standard de Internet (conform Ubuntu) pentru a determina ora. De asemenea, permite interogarea pe IP 10.0.2.0/24:
restriction 10.0.2.0 mask 255.255.255.0 nomodify notrap
Computerul B. are o configurare NTP normală, cu excepția faptului că toate sursele sunt modificate pentru a fi utilizate 10.0.2.1 (care este computerul A).
Din când în când, computerul A primește un semnal Kiss-of-Death de la una dintre sursele sale. Ca rezultat, ucide complet NTP-ul computerului B (adică se pare că KoD-ul este transmis direct).
Există o modalitate de a afla starea unui server NTP în ceea ce privește dacă va trimite doar mesaj KoD sau nu? (de asemenea, cum să ies din acea situație? Când m-am uitat la ea, toate adresele IP afișate în jurnal nu au fost folosite de server?! așa că nu înțeleg de ce insistă să trimită KoD către clientul său) .
Am gasit doua lucruri pana acum:
ntpq
pot sa fug ntpq ca astfel:
ntpq -pn
Când serverul NTP funcționează, pot vedea un asterisc în fața adresei IP de care computerul este mulțumit. În cazul meu, toate indicatoarele de stare (prima coloană +, -, *, #, etc.) toate dispar. Din câte știu, asta înseamnă că serviciul NTP nu este mulțumit și nu se efectuează nicio sincronizare.
Iată un exemplu când încă funcționează (adică există steaguri chiar în prima coloană):
telecomandă refid st t când sondaj atinge întârziere 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>
The ntpdate comanda îmi va spune de fapt dacă NTP acceptă pachete. Acest lucru se datorează faptului că dă un mesaj de eroare dacă nu:
$ sudo ntpdate -q 10.0.2.1
server 10.0.2.1, stratul 4, offset 5.194725, întârziere 0.02652
21 iulie 15:22:48 ntpdate[13086]: nu a fost găsit niciun server adecvat pentru sincronizare
Acest lucru se întâmplă după puțin timp când serverul meu principal pierde * starea pe un singur server cu care a fost bucuros să se sincronizeze mai întâi...
Acum... încă trebuie să înțeleg ce trebuie să fac pentru a remedia această problemă...
Acest lucru poate fi util, iată jurnalele despre o repornire de la o repornire completă:
21 iulie 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
21 iulie 18:29:13 vm-ve-ctl ntpd[3896]: ntpd [email protected] (1): Pornire
21 iulie 18:29:13 vm-ve-ctl ntpd[3896]: Linia de comandă: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 126:129
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: proto: precizie = 0,190 usec (-22)
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Nu se poate deschide fișierul de jurnal /var/log/ntp.log: Permisiune refuzată
21 iulie 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"
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: fișier leapsecond ('/usr/share/zoneinfo/leap-seconds.list'): semnătură hash bună
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: fișier leapsecond ('/usr/share/zoneinfo/leap-seconds.list'): încărcat, expire=2021-12-28T00:00:00Z ultima =2017-01-01T
00:00:00Z ofs=37
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați și introduceți 0 v6wildcard [::]:123
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați și introduceți 1 v4wildcard 0.0.0.0:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 2 lo 127.0.0.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 3 enp0s3 192.168.2.120:123
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 4 enp0s8 10.0.2.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 5 lo [::1]:123
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 6 enp0s3 [fe80::a00:27ff:fe25:38ff%2]:123
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: Ascultați normal pe 7 enp0s8 [fe80::a00:27ff:fe35:c30b%3]:123
21 iulie 18:29:13 vm-ve-ctl ntpd[3901]: ascultare pe soclul de rutare pe fd #24 pentru actualizări de interfață
21 iulie 18:29:14 vm-ve-ctl ntpd[3901]: Solicitare server pool 51.77.203.211
21 iulie 18:29:15 vm-ve-ctl ntpd[3901]: Solicitare server pool 159.69.25.180
21 iulie 18:29:15 vm-ve-ctl ntpd[3901]: Solicitarea serverului de pool 72.5.72.15
21 iulie 18:29:16 vm-ve-ctl ntpd[3901]: Solicitare server pool 198.251.86.68
21 iulie 18:29:16 vm-ve-ctl ntpd[3901]: Solicitare server pool 173.0.48.220
21 iulie 18:29:16 vm-ve-ctl ntpd[3901]: Solicitare server pool 38.229.56.9
21 iulie 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 150.136.0.232
21 iulie 18:29:17 vm-ve-ctl ntpd[3901]: Solicitare server pool 94.154.96.7
21 iulie 18:29:17 vm-ve-ctl ntpd[3901]: Solicitare server pool 137.190.2.4
21 iulie 18:29:18 vm-ve-ctl ntpd[3901]: Solicitare server pool 162.159.200.123
21 iulie 18:29:18 vm-ve-ctl ntpd[3901]: Solicitare server pool 216.218.254.202
21 iulie 18:29:18 vm-ve-ctl ntpd[3901]: Solicitare server pool 91.189.91.157
21 iulie 18:29:19 vm-ve-ctl ntpd[3901]: Solicitare server pool 91.189.89.199
21 iulie 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 74.6.168.73
21 iulie 18:29:19 vm-ve-ctl ntpd[3901]: Solicitare server pool 204.2.134.163
21 iulie 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.89.198
21 iulie 18:29:20 vm-ve-ctl ntpd[3901]: Solicitare server pool 216.229.0.49
21 iulie 18:29:20 vm-ve-ctl ntpd[3901]: Solicitare server pool 2604:ed40:1000:1711:d862:f5ff:fe4e:41c4
21 iulie 18:29:21 vm-ve-ctl ntpd[3901]: primiți: amprenta orară a originii neașteptate 0xe4a34871.ac57f05d nu se potrivește cu aorg 0000000000.00000000 de la [email protected].
Nu știu exact când începe să meargă rău. Am văzut, de asemenea, următoarele despre care am crezut că ar putea avea ceva de-a face cu asta (adică, când se întâmplă acest lucru, IP-ul corespunzător este eliminat din listă!), Dar este deja rău acum și nu a apărut o astfel de eroare în ultima mea rulare.
Jul 21 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 local addr 192.168.2.120 -> <null>
Notă: 192.168.2.120 este IP-ul computerului defect. Este un VirtualBox. Funcționează de luni de zile... totuși, poate s-a schimbat ceva care îl face nefericit.
am găsit acest post despre o problemă cu ... -> <null> mesaj. Cu toate acestea, cred că avem o versiune mai nouă pe Ubuntu 18.04:
Versiunea minimă recomandată SUSE: ntp-4.2.8p7-11.1
Versiunea Ubuntu 18.04: 1:4.2.8p10+dfsg-5ubuntu7.3
Pentru orice eventualitate, am încercat să conectez VM-ul la gazdă și încă am un offset și un jitter uriaș. Ce s-ar fi putut schimba?!
telecomandă refid st t când sondaj atinge întârziere offset jitter
==================================================== =============================
10.0.2.10 .PISCINA. 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
După cum a cerut Paul Gear, iată rezultatul ntpq cu detalii suplimentare:
$ ntpq -ncrv
associd=0 status=0028 leap_none, sync_unspec, 2 evenimente, no_sys_peer,
version="ntpd [email protected] (1)", procesor="x86_64",
system="Linux/4.15.0-151-generic", leap=00, strat=4, precizie=-23,
rootdelay=17.930, rootdisp=5019.260, refid=173.255.215.209,
reftime=e4a44f7a.1c2ec778 joi, 22 iulie 2021 13:11:38.110,
clock=e4a45030.c8a4b259 joi, 22 iulie 2021 13:14:40.783, peer=0, tc=6,
mintc=3, offset=-109,527915, frecvență=-1,707, sys_jitter=0,000000,
clk_jitter=38.724, clk_wander=0.000, tai=37, leapsec=201701010000,
expiră=202112280000
Iată lista ceasurilor disponibile și cea utilizată în prezent:
$ 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
Și, în cele din urmă, dmesg rezultate despre procesul de selectare a sursei de ceas:
$ 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: S-a comutat la 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
