NTP est en cours d'exécution, l'horloge système n'est toujours pas à l'heure - qu'est-ce qui donne?
Un serveur Debian Stable (5.0.3) exécute ntpd et est connecté à Internet. Pourtant, l'horloge système est erronée d'environ 5 minutes.
$ /etc/init.d/ntp status
NTP server is running..
Les parties pertinentes (je pense) de /etc/ntp.conf:
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 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Je sais NTP ne met pas nécessairement l'horloge à l'heure immédiatement. Pourtant, combien d'heures ou de jours vous devez attendre pour raisonnablement vous attendre à ce que NTP a fait son travail et synchronisé l'horloge?
Suis-je en train de manquer un autre fichier de configuration ou une autre option, ou simplement de faire quelque chose de mal? ntp (au lieu de par exemple ntpdate ) est-il le bon outil pour cela? Existe-t-il un moyen rapide de vérifier si la configuration est correcte et si les serveurs choisis NTP renvoient l'heure correcte?
Edit : sortie de ntpq -p est:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000
sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Édition 2 : s'avère ntpdate -u 0.europe.pool.ntp.org commande ( suggérée par brent ) renvoie
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... même si sur d'autres machines cette commande fonctionne bien. Nous allons donc examiner les paramètres de réseau/pare-feu pour ce serveur particulier (qui se trouve dans un réseau différent, accessible via VPN).
Résolution : Le coupable n'était pas le pare-feu local sur notre serveur, mais les paramètres du pare-feu quelque part dans le réseau environnant. Nous avons donc demandé au fournisseur d'hébergement de serveur d'autoriser NTP pour nos machines, et maintenant cela fonctionne bien. Par exemple, ntpq -p renvoie maintenant:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001
ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001
ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(Nous sommes également passés aux serveurs eunet.fi recommencés par la société d'hébergement, mais c'est à côté du point.) Les commandes dans réponse de brent ont été utiles car elles m'ont fait réaliser que le problème était dans l'accès réseau à la NTP serveurs, pas dans la configuration NTP elle-même. Merci à tous!)
Arrêtez ntpd, exécutez ntpdate -u 0.europe.pool.ntp.org 3 fois, lancez ntpd, vérifiez ntpq -p, le délai, le décalage et la gigue doivent être différents de zéro.
Si je devais deviner pourquoi et en supposant que vous avez une connectivité réseau et que vous puissiez voir votre NTP hôte sans problème, alors il se pourrait que vous ayez dérivé vers une grande valeur. Si le décalage horaire est plus grand que X (Désolé, je ne me souviens pas de ce que X est à la légère) qu'un avertissement sera imprimé et l'heure ne sera pas synchronisée. Vous pouvez vérifier vos messages syslog pour les cas de cela.
Si c'est le cas, arrêtez NTP, exécutez ntpdate Host et redémarrez le NTPD, cela forcera une synchronisation temporelle, puis commencez à le garder synchronisé à l'avenir, si vous continuez à dériver autant, vous pouvez avoir un problème matériel.
Les colonnes "portée" étant 0 suggère qu'il n'a pas été en mesure de parler aux serveurs - iirc, il obtient progressivement des bits décalés pour montrer comment les 8 dernières tentatives se sont déroulées (donc 377 est bon, 0 est mauvais).