Donc, j'essaie de déboguer ma configuration NTP actuelle, et j'ai constaté que le décalage par rapport à mon serveur configuré unique dure plus de 3 secondes et ne s'ajuste pas. L'astérisque sur le LOCAL (0) dans la sortie ntpq semble indiquer que le système se synchronise avec lui-même plutôt que le serveur 10.130.33.201 (qui est une autre boîte Linux sur notre système sur laquelle nous voulons que tout se synchronise).
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
Et ceci est mon fichier ntp.conf. Écrit par quelqu'un d'autre, donc je ne suis pas sûr à 100% que tout est correct.
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
J'ai lu au sujet de la rafale et iburst et minpoll / maxpoll, donc je me rends compte que ceux-ci pourraient ne pas être nécessaires, mais je ne pense pas que cela ait quelque chose à voir avec mon problème actuel.
De plus, en raison de la façon dont il est déployé, ce fichier de configuration prendra beaucoup de travail à modifier, donc j'espère qu'il n'y a vraiment rien à changer. J'espère que c'est un cas où je ne comprends pas comment fonctionne NTP.
ÉDITER -
Donc, il semble que ce soit un doublon de Cette question , mais je ne pense pas que l'affiche ait obtenu une réponse suffisante, donc je voudrais toujours savoir pourquoi l'heure locale est préférée au serveur. De plus, selon l'une des réponses ci-dessous, j'ai essayé d'utiliser le prefermot - clé sur la ligne du serveur de la configuration et de redémarrer, mais cela ne semble pas avoir eu d'effet.
Si je supprime toutes les lignes "locales" de la configuration comme le suggère la réponse à l'autre question, que se passera-t-il si le serveur est inaccessible? Le NTP meurt-il ou continue-t-il à essayer?
MODIFICATION IMPORTANTE -
Ok, normalement, 10.130.33.201 (le "serveur") n'a pas accès à Internet et n'a pas de source horaire GPS à utiliser. La partie importante est que tous les périphériques du système ont la même heure que le serveur, quelle que soit l'heure exacte.
Donc, juste pour voir ce qui se passerait, j'ai ajouté l'un des serveurs de pool NTP au fichier de configuration du serveur afin qu'il obtienne du temps à partir de là plutôt que du temps local. Il obtient désormais correctement l'heure du serveur de temps NTP.
Après cela, les clients se synchronisent maintenant avec le serveur plutôt que de préférer 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
NOUVELLE QUESTION - Lorsque mon serveur utilise local (exemple original qui a été donné), il semble que les clients disent: "Oh, 10.130.33.201 utilise LOCAL (0). Hmm, j'ai aussi un serveur LOCAL (0) - - Je vais simplement l'utiliser directement plutôt que d'obtenir les mêmes informations via 10.130.33.201 ".
Est-ce le cas? Essayent-ils d'aller "directement à la source" qui est incorrectement LOCAL (0)? J'ai besoin que mon serveur obtienne l'heure de LOCAL (0), et j'ai besoin que les clients obtiennent l'heure du serveur. En ce moment, la suppression du serveur "local" des fichiers de configuration du client est la seule option, mais je voudrais comprendre pourquoi cela se produit, et si possible, éviter de changer leurs configurations (le changement de configuration sera beaucoup de travail à cause de notre environnement...).
En outre, cela ressemble à un autre doublon sans bonne réponse.