Quindi, sto provando a eseguire il debug della mia attuale configurazione NTP e ho scoperto che l'offset dal mio singolo server configurato è di oltre 3 secondi e non si sta adeguando. L'asterisco su LOCAL (0) nell'output ntpq sembra indicare che il sistema si sta sincronizzando felicemente con se stesso piuttosto che con il server 10.130.33.201 (che è un altro box Linux sul nostro sistema con cui vogliamo che tutto si sincronizzi).
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.130.33.201 LOCAL(0) 9 u 49 64 377 0.242 -3742.2 1.049
*LOCAL(0) .LOCL. 10 l 2 64 377 0.000 0.000 0.001
E questo è il mio file ntp.conf. Scritto da qualcun altro, quindi non sono sicuro al 100% che tutto sia corretto.
server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift
restrict -4 default nomodify nopeer notrap
restrict -6 default ignore
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
Ho letto di burst e iburst e minpoll / maxpoll, quindi mi rendo conto che quelli potrebbero non essere necessari, ma non penso che ciò abbia a che fare con il mio problema attuale.
Inoltre, a causa del modo in cui è distribuito, quel file di configurazione richiederà molto lavoro per cambiare, quindi spero che non ci sia nulla che debba davvero essere cambiato. Spero che questo sia un caso in cui non capisco come funziona NTP.
MODIFICARE -
Quindi, sembra che questo sia un duplicato di questa domanda , ma non credo che quel poster abbia una risposta sufficiente, quindi vorrei ancora sapere perché l'ora locale è preferita al server. Inoltre, come da una delle risposte di seguito, ho provato a utilizzare la preferparola chiave sulla riga del server della configurazione e riavviare, ma ciò non sembra aver avuto effetto.
Se rimuovo tutte le righe "locali" nella configurazione come suggerisce la risposta all'altra domanda, cosa accadrà se il server non è raggiungibile? L'NTP muore o continua a provare?
MODIFICA IMPORTANTE -
Ok, normalmente, 10.130.33.201 (Il "server") non ha accesso a Internet e non ha una fonte di tempo GPS da usare. La parte importante è che tutti i dispositivi sul sistema hanno lo stesso orario del server, indipendentemente dalla correttezza di tale orario.
Quindi, solo per vedere cosa sarebbe successo, ho aggiunto uno dei server del pool NTP al file di configurazione del server in modo da ottenere tempo da lì piuttosto che ottenere da locale. Ora ottiene correttamente l'ora dal time server NTP.
Dopo averlo fatto, i client ora si sincronizzano con il server piuttosto che preferiscono LOCAL (0)
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.130.33.201 38.229.71.1 3 u 58 64 377 0.216 715621. 1.001
LOCAL(0) .LOCL. 10 l 18 64 377 0.000 0.000 0.001
NUOVA DOMANDA - Quando il mio server utilizza local (esempio originale che è stato fornito), sembra che i client stiano dicendo "Oh, 10.130.33.201 sta usando LOCAL (0). Hmm, ho anche un server LOCAL (0) - - Lo userò direttamente invece di ottenere le stesse informazioni tramite 10.130.33.201 ".
È così? Stanno cercando di andare "direttamente alla fonte" che è erroneamente LOCALE (0)? Ho bisogno che il mio server ottenga il tempo da LOCAL (0) e ho bisogno che i client ottengano il tempo dal server. In questo momento la rimozione del server "locale" dai file di configurazione del client è l'unica opzione, ma vorrei capire perché ciò sta accadendo e, se possibile, evitare di cambiare le loro configurazioni (la modifica della configurazione sarà molto impegnativa a causa di il nostro ambiente...).
Inoltre, questo sembra un altro duplicato senza una buona risposta.