Gdy pytam o status demona NTP za pomocą ntpdc -c sysinfo
, otrzymuję następujące dane wyjściowe:
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -20
root distance: 0.00000 s
root dispersion: 12.77106 s
reference ID: [73.78.73.84]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
Oznacza to, że synchronizacja NTP nie powiodła się. Jednak czas systemowy jest dokładny z dokładnością do 1 sekundy. Gdy uruchomiłem mój system bez połączenia sieciowego przez ten sam okres, co teraz, czas w systemie może się różnić od 10 do 10 sekund.
To zachowanie sugeruje, że system ma inny sposób synchronizacji czasu. Uświadomiłem sobie, że istnieje też systemd-timesyncd.service
(z plikiem konfiguracyjnym w /etc/systemd/timesyncd.conf
) i timedatectl status
podałem prawidłowy czas:
Local time: Thu 2016-08-25 10:55:23 CEST
Universal time: Thu 2016-08-25 08:55:23 UTC
RTC time: Thu 2016-08-25 08:55:22
Time zone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2016-03-27 01:59:59 CET
Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2016-10-30 02:59:59 CEST
Sun 2016-10-30 02:00:00 CET
Więc moje pytanie brzmi, jaka jest różnica między tymi dwoma mechanizmami? Czy jeden z nich jest przestarzały? Czy można ich używać równolegle? Któremu zaufać, jeśli chcę sprawdzić status synchronizacji NTP?
(Zauważ, że mam inny system (w innej sieci), dla którego obie metody wskazują sukces i dają właściwy czas.)
Odpowiedzi:
systemd-timesyncd to w zasadzie niewielka implementacja NTP tylko dla klienta, mniej więcej w pakiecie z nowszymi wydaniami systemowymi. Jest bardziej lekki niż pełna ntpd, ale obsługuje tylko synchronizację czasu - tzn. Nie może działać jako serwer NTP dla innych komputerów. Jest przeznaczony do zastąpienia ntpd dla klientów.
Nie należy używać obu równolegle, ponieważ teoretycznie mogą wybierać różne serwery czasu, które mają między nimi niewielkie opóźnienie, co powoduje, że zegar systemowy jest okresowo „przeskakiwany”.
Aby uzyskać status, niestety musisz użyć,
ntpdc
jeśli używasz ntpd itimedatectl
jeśli używasz timesyncd, nie znam żadnego narzędzia, które mogłoby odczytać oba.źródło
systemd-timesyncd nie dyscyplinuje zegara: zegar nie jest trenowany ani kompensowany, a dryf zegara wewnętrznego w czasie nie ulega zmniejszeniu. Ma podstawową logikę, aby dostosować interwał odpytywania, ale bez dyscypliny gospodarz skończy z nierównomiernym czasem na zawsze, gdy systemd-timesyncd popycha lub ściąga w dowolnym interwale, jaki według niego wymaga krótkotrwałego dryfu. Nie może również ocenić jakości zdalnego źródła czasu. Jest mało prawdopodobne, aby uzyskać dokładność znacznie większą niż 100 ms. Jest to wystarczające w przypadku prostych urządzeń użytkowników końcowych, takich jak laptopy, ale może zdecydowanie powodować problemy w systemach rozproszonych, które wymagają większej precyzji czasu.
źródło