Wiadomości oznaczają, że Twój serwer ntpd szuka więcej źródeł czasu do synchronizacji. Spodziewane jest zobaczenie kilku z nich, szczególnie po ponownym połączeniu z siecią po awarii lub ponownym uruchomieniu, ale jeśli twój ntpd i połączenie sieciowe działają płynnie, nie powinno być więcej niż kilka dziennie. Jeśli masz kilka co kilka minut, prawdopodobnie jest to problem.
Czy Twój ntpd łączy się z urządzeniami równorzędnymi i pomyślnie synchronizuje czas? Możesz to sprawdzić za pomocą ntpq
. Spójrz na listę peerów ntpq -c pe
i zgłoszoną warstwę i czas odnowienia w ntpq -c rv
. Warstwa 16 oznacza „niezsynchronizowany”.
To:
user@localhost $ ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
de.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.002
user@localhost $ ntpq -c rv
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p10@1.3728-o Tue Jun 20 08:08:18 UTC 2017 (1)",
processor="x86_64", system="Linux", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=0.090, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
clock=dde6bdf4.dec8453b Fri, Dec 22 2017 0:10:44.870, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=4.981, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000
oznacza, że twój NTP tak naprawdę nie działa (w tym przypadku, ponieważ właśnie go uruchomiłem), podczas gdy:
user@localhost $ ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
cz.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.002
+mail.nettel.cz 195.113.144.201 3 u 4 64 377 5.215 -0.842 0.332
*fedecks.wuji.cz 195.113.144.238 2 u 61 64 377 2.121 -2.005 0.171
-lx.ujf.cas.cz .GPS. 1 u 62 64 177 2.662 -0.714 0.215
-pyrrha.fi.muni. 195.113.144.238 2 u 63 64 177 7.445 -0.697 0.340
-host-81-200-57- 192.168.3.246 2 u 55 64 177 15.792 0.098 1.160
cz.inthouse.clo 147.231.2.6 2 u 47 64 17 5.338 -0.266 0.461
user@localhost $ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Sat Jul 29 07:38:14 UTC 2017 (1)",
processor="ppc", system="Linux", leap=00, stratum=2,
precision=-19, rootdelay=2.652, rootdisp=4.409, refid=147.231.100.5,
reftime=dde6be4a.f90912d6 Fri, Dec 22 2017 0:12:10.972,
clock=dde6be4d.12f27b56 Fri, Dec 22 2017 0:12:13.074, peer=10703, tc=6,
mintc=3, offset=-0.387828, frequency=-254.539, sys_jitter=1.572660,
clk_jitter=0.456, clk_wander=0.098
oznacza, że Twój NTP działa poprawnie.
Jeśli nie synchronizuje się i pozostaje przez długi czas, prawdopodobnie masz problem z siecią lub konfiguracją. Zobacz man 5 ntp.conf
pomoc i stronę pomocy NTP.org na temat konfiguracji przykładów. W moim przypadku przyczyną niekończącego się spamu „namawianie serwera puli” była nopeer
dyrektywa, która musi być wyłączona dla serwerów puli.