ntpd vs. systemd-timesyncd - Come ottenere una sincronizzazione NTP affidabile?

Quando chiedo lo stato del demone NTP con ntpdc -c sysinfoottengo il seguente output:

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

Ciò indica che la sincronizzazione NTP non è riuscita. Tuttavia, il tempo di sistema è preciso con precisione di 1 secondo. Quando eseguivo il mio sistema senza connessione di rete per lo stesso periodo di adesso, il tempo di sistema si discostava di ~ 10 secondi.

Questo comportamento suggerisce che il sistema ha un altro modo di sincronizzare il tempo. Mi sono reso conto che c'è anche systemd-timesyncd.service(con il file di configurazione in /etc/systemd/timesyncd.conf) e timedatectl statusmi dà l'ora corretta:

      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

Quindi la mia domanda è qual è la differenza tra i due meccanismi? Uno di questi è deprecato? Possono essere usati in parallelo? Quale dovrei fidarmi quando voglio interrogare lo stato di sincronizzazione NTP?

(Si noti che ho un sistema diverso (in una rete diversa) per il quale entrambi i metodi indicano il successo e danno il tempo corretto.)

ntp ntpd

— un ospite
fonte

Ho scoperto che Fedora utilizza effettivamente chrony : Configurare NTP usando chrony Suite

— David Tonhofer,

Risposte:

systemd-timesyncd è fondamentalmente una piccola implementazione NTP solo per client più o meno in bundle con le nuove versioni di systemd. È più leggero di un ntpd completo ma supporta solo la sincronizzazione temporale, ovvero non può fungere da server NTP per altre macchine. È destinato a sostituire ntpd per i client.

Non dovresti usarli entrambi in parallelo, poiché in teoria potrebbero scegliere diversi timeserver che hanno un leggero ritardo tra loro, portando il tuo orologio di sistema a essere periodicamente "nervoso".

Per ottenere lo stato, sfortunatamente è necessario utilizzare ntpdcse si utilizza ntpd e timedatectlse si utilizza timesyncd, non conosco alcuna utilità in grado di leggere entrambi.

— MaxF
fonte

Come è possibile quindi che su un sistema la sincronizzazione di ntpd stia fallendo mentre sull'altro ha successo (entrambi eseguono systemd-timesyncd in parallelo). Sono abbastanza certo che ciò non riguardi un problema con il firewall poiché ho verificato le impostazioni corrispondenti. In questo momento sono rimasto con due risultati e sono tentato di fidarmi di quello di successo, tuttavia ho dei dubbi poiché entrambi i client implementano lo stesso protocollo NTP ma uno non funziona. In realtà mi aspetterei che funzionino entrambi.

— a_guest,

ntpd e timesyncd usano impostazioni diverse. Hai impostato lo stesso timeserver per entrambi?

— massimo

puoi usare timesyncd per sincronizzare l'ora con un GPS come con ntp?

— Bakalolo,

Systemd-timesyncd è un client SNTP che è meno preciso di NTP. I lettori non devono essere indotti in errore nel pensare che systemd-timesyncd sia un client NTP leggero.

— Philip Couling,

systemd-timesyncd non disciplina l'orologio: l'orologio non viene allenato o compensato e la deriva dell'orologio interno nel tempo non viene ridotta. Ha una logica rudimentale per regolare l'intervallo di polling, ma senza disciplinare l'host finirà con un tempo irregolare per sempre mentre systemd-timesyncd spinge o tira a qualsiasi intervallo pensi che la deriva a breve termine richieda. Inoltre, non è in grado di valutare la qualità dell'origine temporale remota. È improbabile che tu abbia una precisione molto maggiore di 100ms. Questo è sufficiente per semplici dispositivi per utenti finali come i laptop, ma potrebbe sicuramente causare problemi ai sistemi distribuiti che desiderano una maggiore precisione temporale.

— Metaxis
fonte