Pourquoi ntpd ne met-il pas à jour l'heure sur mon serveur?

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 cours 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'informations # 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 # 3

J'ai désinstallé ntp et installé openntpd /usr/sbin/ntpd -det j'ai couru , 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'informations # 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.

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.

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 d'écrire ces ntpdate -q ntp.ubuntu.comlignes , montre que mon temps est précis à moins de 0,000216 secondes. 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 s'élève à des fractions de seconde, même sur des systèmes très chargés. Cette légère imprécision est facilement gérée par NTP même si elle n'est définie que pour mettre à jour l'heure des serveurs une fois par jour (ou même moins fréquemment que cela).

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 l'occupation globale du vhost.

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 finiront probablement par abandonner, avec le résultat qui ntp -npmontre les serveurs de temps que ntp a jugés inappropriés.

Votre meilleur pari si c'est le cas est probablement une force brute de rdate -s $servertemps 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.

Choses que j'ai trouvées dans le passé, quand j'ai utilisé ntpd au lieu de openntpd:

1. Vous devez autoriser l'accès à localhost pour que ntpd démarre correctement et fasse des choses

   restrict 127.0.0.1
   restrict ::1
   

2. Bien que vous puissiez utiliser des noms d'hôte pour les règles de serveur, ouvrir des trous de sauvegarde pour parler avec ces serveurs signifie utiliser des restrictadresses IP qui nécessitent, donc j'ai finalement dû utiliser des IP pour tout.

3. Vous ne mentionnez pas l'utilisation restrictpour ouvrir l'accès à 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
   

4. Vous avez besoin de plusieurs pairs ou serveurs pour ntpd, car il essaie d'utiliser le vote majoritaire 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.

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 ignorecomme vous quand ntpd 4.2 a changé le sens de notrust. soupir

6. 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 openntpdplutôt envisager . É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.

• Si ntpd ne pouvait pas se connecter au serveur distant, vous ne verriez pas de décalage pour ce serveur.
• Si ntpq est bloqué par ntpd, vous verrez un message d'erreur clair de ntpq.
• Si un autre service définissait également l'heure (comme les outils vmware), vous verriez un décalage de saut pour le serveur (exécutez ntpq -p toutes les 70 secondes).

La reach 7sortie in 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 ( pollvaleur) et a déjà attendu 30 secondes ( whenvaleur) depuis le dernier contact.

L' offset -0.136indiqué, 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 a besoin d'être modifié pour y arriver.

Dans /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Je mets ça à yes . Bien sûr, vérifiez d'abord que vous disposez d'un serveur NTP solide 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 de nombreux NAS ne fonctionneront 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