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


20

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.


C'est tout votre fichier de configuration? Si vous exécutez ntpq -np, quelle est la sortie?
David Mackintosh

Où est le reste de la config? Il n'y a pas de serveur en amont pour que votre hôte puisse obtenir du temps.
Aaron Copley

6
Je l'ai. Il semble que ntpd fonctionnait normalement. NTPd "ramènera" votre horloge en synchronisation progressivement. Un changement brusque de temps peut causer de gros problèmes pour certains processus en cours d'exécution, donc NTP fonctionne en accélérant ou en ralentissant la durée d'une seconde pour effectuer progressivement des ajustements.
Aaron Copley

1
Oui, le noyau démarrera avec l'horloge matérielle au démarrage, car au démarrage, c'est sa seule référence. Si cela fonctionne depuis plusieurs mois, comme vous le dites, ce n'est pas ça. Vous pouvez demander à NTP de se synchroniser avec votre horloge matérielle. Je ne suis pas sûr d'Ubuntu mais sur les systèmes basés sur Red Hat qui se trouvent dans / etc / sysconfig / ntpd. Vous pouvez y regarder ou vous référer à la documentation de votre matériel.
Aaron Copley

1
Je ne pense pas non plus que vous compreniez que ntpdate est une application autonome. Il n'a rien à voir avec ntpd et ne doit pas être utilisé pour le dépanner. La raison pour laquelle ntpq a été suggérée avec les options -p pour afficher l'homologation. Si ntpd voit vos pairs, alors il devrait ramener le système en synchronisation. On dirait que tout va bien maintenant. J'espérais juste fournir un aperçu supplémentaire. J'espère que cela vous aidera à l'avenir!
Aaron Copley

Réponses:


10

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.


ntpdate est heureux de faire son truc - Mais je me demande si lorsque mon serveur redémarre, l'horloge est réinitialisée sur l'horloge du matériel ou quelque chose du genre?
John Bachir

Après avoir utilisé ntpdate pour régler l'horloge, utilisez 'hwclock --systohc' pour synchroniser le temps de "fonctionnement" avec votre horloge matérielle. Il est censé se synchroniser au redémarrage, mais si votre machine tombe en panne (ou a eu un problème lors d'un arrêt correct), elle ne pourra pas la synchroniser.
Dave Drager

Eh bien, c'est un vhost, donc je n'ai pas accès à l'horloge matérielle (au moins j'espère que non!)
John Bachir

Il y a une horloge matérielle émulée tout comme il y a un BIOS émulé.
Keith Stokes

J'étais l'administrateur de plusieurs plates-formes VPS, aucune d'entre elles (openvz, Xen) n'a accès pour régler l'horloge sur le système. Tout devait être fait au niveau de l'hôte. Soumettez un ticket à votre hôte pour indiquer que l'heure est désactivée, il devrait exécuter ntp et synchroniser l'heure pour vous.
Dave Drager

7

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).


4

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.


Mon hébergeur (cloud cloud) m'a dit que NTP fonctionnait bien dans leur environnement.
John Bachir

Voir ma réponse soumise / acceptée pour ce que mon fournisseur VPS a dit à propos de l'horloge et l'accès au réglage de l'heure.
John Bachir

La mise à jour automatique peut faire reculer l'horloge, ce qui peut avoir de nombreuses conséquences inattendues.
rackandboneman

4

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.


Ce sont d'excellentes informations. Je vérifie openntpd. Question: êtes-vous d'accord ou en désaccord avec les autres personnes qui prétendent qu'il est impossible de régler l'horloge sur un vhost?
John Bachir

Et vous pouvez peut-être répondre à cette question: serverfault.com/questions/223511/…
John Bachir

Je ne comprends pas ce que vous dites avec vos différentes restrictrègles… ces règles affectent-elles également les serveurs sur lesquels je peux interroger du temps? Je pensais que cela n'affectait que les nœuds qui pouvaient me demander du temps.
John Bachir

1
Voici une idée: vous voulez changer votre réponse en un fichier ntp.conf minimal complet avec des commentaires? :-)
John Bachir

Il est déconseillé de régler l'horloge sur un vhost, à moins que vous ne soyez assuré d'être toujours programmé avec au moins un processeur, car sinon l'heure perçue par le vhost ne correspond pas à l'heure du monde extérieur. Le dom0 doit maintenir le temps. La réponse à l'autre question est bonne. NTP est UDP, vous devez donc autoriser les paquets des serveurs que vous interrogez pour le temps. Mon ntpd est périmé lorsque je suis passé à OpenNTPD il y a quelques années.
Phil P

3
  • 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.


Excellente première réponse, Robert. Bienvenue sur le site.
kubanczyk

1

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!


1
Snap .. c'est pertinent pour RHEL / Centos. Peut-être pas Ubuntu.
Wayne Sweatt


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.