J'ai ntpd en cours d'exécution sur mon serveur. Ce sont tous les paramètres par défaut, sauf que j'ai commenté sa capacité à être un serveur pour d'autres machines:
# restrict -4 default kod notrap nomodify nopeer noquery
# restrict -6 default kod notrap nomodify nopeer noquery
restrict default ignore
Si je lance ntpdate -q ntp.ubuntu.com
, On me dit que l'horloge de ma machine est éteinte de 7 secondes.
Que se passe-t-il? Comment puis-je diagnostiquer ce qui se passe, existe-t-il un journal que je peux activer?
plus d'infos # 1
# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
91.189.94.4 193.79.237.14 2 u 30 64 7 108.518 -0.136 0.361
plus d'informations # 2
Voici à quoi cela ressemblait lorsque j'ai posé la question:
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec
Et voici à quoi cela ressemble maintenant, après avoir redémarré ntpd plusieurs fois (je suppose que c'est ce qui l'a corrigé):
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec
plus d'informations #
J'ai désinstallé ntp et installé openntpd et j'ai exécuté /usr/sbin/ntpd -d
, et je vois une sortie comme celle-ci:
reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s
Ce qui pour moi indique assez clairement que je ne suis pas en mesure de régler l'heure sur mon serveur (bien que, avec le ntp normal, il semble parfois se mettre à jour ...).
plus d'infos # 4
Mon fournisseur VPS dit:
Les derniers noyaux ne devraient pas verrouiller votre système sur l'horloge de notre dom0, pour être sûr, vous pouvez définir xen.independent_wallclock = 1 dans votre sysctl.conf.
Ce qui, je suppose, ne résout toujours pas le problème du VPS nécessitant un processeur disponible afin de faire des calculs de synchronisation corrects.
Très bien, depuis que j'ai posé cette question, j'ai réinstallé ntp avec la configuration par défaut du fournisseur (Ubuntu 10.0.4) et je l'ai laissé fonctionner pendant quelques jours. Au moment de la rédaction de cet article, ntpdate -q ntp.ubuntu.com
montre que mon temps est précis à 0,000216 seconde près. Donc, les problèmes que je rencontrais doivent avoir été avec ma configuration personnalisée (où j'essayais d'empêcher les hôtes externes d'interroger mon serveur, ce que je fais déjà avec mon pare-feu, donc je ne suis pas trop inquiet). Voici le Ubuntu 10.0.4 ntp.conf dans son intégralité, avec les commentaires supprimés:
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 ntp.ubuntu.com
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
Je me réjouis des commentaires sur la façon dont cette configuration pourrait être améliorée.
J'ai également fait un ticket avec mon fournisseur VPS pour leur demander une recommandation détaillée sur la meilleure chose à faire. Je les ai dirigés vers ce fil, et d'autres documents indiquant que peut-être l'allocation de CPU causerait un problème de synchronisation. Voici ce qu'ils ont dit:
Les derniers noyaux ne devraient pas verrouiller votre système sur l'horloge de notre dom0, pour être sûr, vous pouvez définir xen.independent_wallclock = 1 dans votre sysctl.conf. Cela garantira que l'instance de serveur ne suit pas l'horloge du serveur hôte.
et:
Je pense que vous comprenez peut-être mal dans quelle mesure ce problème affecte les clients NTP dans un environnement virtualisé. D'après mon expérience sur un système virtualisé sur un hôte Xen (comme notre configuration sur Rackspace Cloud), l'inexactitude héritée du fait de ne pas avoir d'horloge système dédiée pour traiter les interruptions équivaut à des fractions de seconde, même sur des systèmes très chargés. Cette légère inexactitude est facilement gérée par NTP même si elle est uniquement mis à jour l'heure des serveurs une fois par jour (ou même moins fréquemment que cela).
Vous pouvez activer la connexion dans ntpd en l'ajoutant à ntp.conf:
logfile /var/log/ntpd.log
Source: manuel ntp
Si vous désactivez ntpd, pouvez-vous mettre à jour l'horloge par ligne de commande? Si vous exécutez la commande ntpdate et recevez une erreur comme ceci:
# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted
Cela signifie que vous êtes probablement sur un VPS, et dans ce cas, vous ne pouvez pas modifier l'horloge système - cela ne peut être fait que sur la machine hôte.
Choses que j'ai trouvées dans le passé, quand j'ai utilisé ntpd au lieu de openntpd:
Vous devez autoriser l'accès à localhost pour que ntpd démarre correctement et fasse des choses
restrict 127.0.0.1
restrict ::1
Bien que vous puissiez utiliser des noms d'hôtes pour les règles de serveur, ouvrir des trous de sauvegarde pour parler avec ces serveurs signifie utiliser restrict
qui nécessite des adresses IP, donc j'ai fini par devoir utiliser des IP pour tout de toute façon.
Vous ne mentionnez pas l'utilisation de restrict
pour ouvrir l'accès de sauvegarde à vos serveurs. Voilà un problème. Essayez des blocs tels que les suivants:
# ntp.xs4all.nl
server 194.109.22.18
restrict 194.109.22.18
Vous avez besoin de plusieurs pairs ou serveurs pour ntpd, car il essaie d'utiliser le vote à la majorité pour traiter un mauvais acteur. Donc un minimum de 4, pour pouvoir encore avoir une majorité quand on en perd un, de préférence 5.
Pour verrouiller l'accès par défaut, je pourrais utiliser:
restrict default notrust nomodify
afin de pouvoir encore interroger, mais j'ai fini par utiliser restrict default ignore
comme vous le faites lorsque ntpd 4.2 a changé la signification de notrust
. soupir
Si vous ne fournissez pas de service de temps à d'autres, alors vous n'avez probablement pas besoin de la pleine puissance de ntpd normal et vous devriez plutôt envisager openntpd
. Écrit par l'équipe d'OpenBSD, c'est une implémentation beaucoup plus minimale, utilisant la séparation des privilèges et un fichier de configuration beaucoup plus simple. Il ne fournirait pas le temps très précis que ntpd fournirait, mais il est facilement suffisant pour un serveur ou un poste de travail normal.
Un de vos commentaires dit que vous utilisez un vhost. Dans ce cas, vous n'aurez probablement pas beaucoup de succès car le sens du temps de votre vhost dépendra à la fois de l'hôte réel sur lequel il s'exécute et de la façon dont le vhost est globalement occupé.
Selon la virtualisation utilisée, le vhost peut ne pas obtenir une part régulière d'interruptions dans une période de temps donnée. Cela rendra l'horloge plus rapide ou plus lente que ce qui se passe réellement. Étant donné que ntp essaie de mesurer les changements en supposant que votre horloge est un taux fixe plus rapide ou plus lent que le reste du monde, cette accélération et ce ralentissement donneront des ajustements ntp et ils finiront probablement par abandonner, avec le résultat cette ntp -np
montre les serveurs de temps que ntp a jugés inappropriés.
Si c'est le cas, votre meilleur pari est probablement une force brute rdate -s $server
de temps en temps (comme toutes les six heures) pour tirer l'horloge par son nez afin qu'elle ne dérive pas excessivement de la synchronisation. Mais une précision fine est probablement hors de portée.
Le reach 7
dans la sortie ntpq indique que vous ne laissez ntpd fonctionner que pendant environ 4 minutes. 7 est 111 binaire, ce qui signifie que le serveur a déjà été atteint 3 fois. ntp atteint toutes les 64 secondes (valeur poll
) et a déjà attendu 30 secondes (valeur when
) depuis le dernier contact.
Le offset -0.136
indique que le système est déjà synchronisé. Seul ntpd n'a pas encore marqué le serveur comme source. Donnez-lui juste plus de temps et une petite étoile apparaîtra.
Donc, en fait, votre ntpd se synchronisait. Mais ntpd ne se synchronise généralement pas en un seul grand saut (comme ntpdate), mais essaie d'ajuster le temps lentement et assure sur plusieurs cycles, que le temps est stable.
PS: Je sais que la question est très ancienne. Mais la question est intemporelle. Et toutes les autres réponses sont simplement trompeuses à mon humble avis. ntpd est même recommandé par VMWare pour garder l'heure synchronisée.
J'ai trouvé mon système éteint et je me suis demandé pourquoi l'horloge matérielle ne se synchronisait pas avec l'horloge système lors d'un arrêt net. Il semble qu'il y ait un paramètre NTP dans sysconfig qui doit être modifié pour y arriver.
Dans /etc/sysconfig/ntpd
:
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
J'ai défini cela sur yes
. Bien sûr, vérifiez d'abord que vous disposez d'un solide serveur NTP et que votre horloge système est fiable.
Je savais que c'était ça - mon biais était de 47 secondes et mon horloge matérielle était également de 47 secondes. Bingo! Mon premier indice était les échecs Kerberos vus dans les journaux. Kerberos et beaucoup NAS ne fonctionnera tout simplement pas si le décalage d'horloge est trop important.
Bonne journée!
si vous exécutez vhost sur vmware, consultez l'article suivant ... il devrait vous aider http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Hai ..
Jetez un œil à cette référence pour voir si elle peut vous aider à résoudre votre problème:
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server
vous voudrez peut-être publier le contenu de votre fichier ntpd.conf, la sortie des commandes de débogage comme ntpq -p
Et vérifiez votre date/heure?
Et vérifiez cela également, exécutez ntpdate et démarrez ntpd, le temps est-il synchronisé?
avec mes meilleurs vœux