Serwer Debian Stable (5.0.3) jest uruchomiony ntpdi podłączony do Internetu. Mimo to zegar systemowy ma około 5 minut nieprawidłowy.
$ /etc/init.d/ntp status
NTP server is running..
Odpowiednie części (jak sądzę) /etc/ntp.conf:
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Wiem, że NTP niekoniecznie natychmiast przynosi czas. Ale ile godzin lub dni musisz poczekać, aby rozsądnie oczekiwać, że NTP wykona swoją pracę i zsynchronizuje zegar?
Czy brakuje mi innego pliku konfiguracyjnego lub opcji, czy po prostu robię coś złego? Czy ntp (zamiast np. Ntpdate ) jest do tego odpowiednim narzędziem? Czy istnieje szybki sposób sprawdzenia, czy konfiguracja jest poprawna i czy wybrane serwery NTP zwracają prawidłowy czas?
Edycja : wyjście ntpq -pto:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000
sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Edycja 2 : Zwraca ntpdate -u 0.europe.pool.ntp.orgpolecenie ( sugerowane przez brent )
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... nawet jeśli na innych komputerach to polecenie działa poprawnie. Przyjrzymy się więc ustawieniom sieci / zapory dla tego konkretnego serwera (który jest w innej sieci, dostępny przez VPN).
Rozwiązanie : sprawcą nie była lokalna zapora ogniowa na naszym serwerze, ale ustawienia zapory ogniowej gdzieś w otaczającej sieci. Poprosiliśmy więc dostawcę hostingu serwerów o zezwolenie na NTP dla naszych maszyn, a teraz działa dobrze. Na przykład ntpq -pteraz zwraca:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001
ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001
ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(Przeszliśmy również na serwery eunet.fi zalecane przez firmę hostingową, ale to nie ma znaczenia). Polecenia w odpowiedzi brenta były pomocne, ponieważ uświadomiły mi, że problem dotyczy dostępu do sieci serwerów NTP, a nie konfiguracji NTP samo. Dziękuję wszystkim!
źródło
Odpowiedzi:
Zatrzymaj ntpd, uruchom
ntpdate -u 0.europe.pool.ntp.org3 razy, uruchom ntpd, sprawdźntpq -p, opóźnienie, przesunięcie i jitter powinny być niezerowe.źródło
ntpdateKomenda działa i synchronizacje mój zegar, ale wszystkie wartości są nadal0po ponownym uruchomieniuntp. Dlaczego miałoby to działać, jeśli robię to ręcznie, ale nie używamntpd? Jestem na Debianie btw.Gdybym musiał zgadywać, dlaczego i zakładając, że masz łączność sieciową i widzisz swojego hosta NTP bez problemu, może to oznaczać, że spadłeś do dużej wartości. Jeśli różnica czasu jest większa niż X (Przepraszam, nie pamiętam, co X jest pod ręką), zostanie wydrukowane ostrzeżenie i czas nie zostanie zsynchronizowany. Możesz sprawdzić swoje wiadomości syslog pod kątem takich przypadków.
W takim przypadku zatrzymaj NTP, uruchom host ntpdate i zrestartuj NTPD, co wymusi synchronizację czasu, a następnie zacznij utrzymywać synchronizację do przodu, jeśli nadal będziesz dryfować, możesz mieć problem ze sprzętem.
źródło
Kolumny „zasięg” wynoszące 0 sugerują, że nie był w stanie rozmawiać z serwerami - iirc stopniowo przesuwa bity, aby pokazać, jak poszło ostatnie 8 prób (więc 377 jest dobre, 0 jest złe).
źródło