NTP : Le client ne se synchronise pas tout seul

Bonjour à tous,
Je suis toujours obligé de redémarrer mon serveur NTP pour “rafraîchir” mon heure. Je perds environ une minute par jour (serveur sur-sollicité). Si je ne redémarre pas le le client manuellement (# /etc/init.d/ntp restart), ça pose des problèmes avec des API qui demandent d’envoyer des heures correctes.

Y’a-t-il moyen de rafraîchir l’heure plus régulièrement ?

Merci d’avance :slightly_smiling: .
BrasDeMehldau

bonsoir.

si c’est bien le paquet ntp que vous avez installé alors vous n’avez aucune mise à l’heure à faire,ntp le fait en continu pour garder en permanence la machine à l’heure.Il suffit que vous lanciez la commande

pour voir ce qui se passe.
Si vous voulez mettre à l’heure à la mano,il faut arrêter le service ntp et ensuite utiliser ntpdate.

Merci de cette réponse rapide, avram.
Il s’agit bien du paquet ntp.

Voici le retour de la commande ntpq -p :

[code]$ ntpq -p
remote refid st t when poll reach delay offset jitter

*ntp.univ-angers 145.238.203.14 2 u 87 128 377 10.097 8.275 124.483
+server5.webster 193.67.79.202 2 u 10 128 357 0.188 15.110 175.415
+ks351056.kimsuf 91.121.122.16 3 u 131 128 377 4.153 13.742 104.076
xns0.serverhouse 249.189.181.45 2 u 4 128 377 0.218 395.450 371.427[/code]

Pour le moment (je viens de redémarrer ntp), mon serveur est bien synchronisé. Mais je suis certain que si je reviens d’ici quelques jours, j’aurai perdu quelques secondes voire minutes.

Edit : Je viens de mettre à jour Debian et le paquet ntp passe à une version supérieure. Peut-être une amélioration en vue ?

BrasDeMehldau

tout semble fonctionner normalement,si vous voulez vérifier une éventuelle dérive du temps laissez passer un jour ou deux,arrêtez ntp et lancez ntpdate et vous pourrez voir si il y a eu dérive.

[quote=“BrasDeMehldau”]Merci de cette réponse rapide, avram.
Il s’agit bien du paquet ntp.

Voici le retour de la commande ntpq -p :

[code]$ ntpq -p
remote refid st t when poll reach delay offset jitter

*ntp.univ-angers 145.238.203.14 2 u 87 128 377 10.097 8.275 124.483
+server5.webster 193.67.79.202 2 u 10 128 357 0.188 15.110 175.415
+ks351056.kimsuf 91.121.122.16 3 u 131 128 377 4.153 13.742 104.076
xns0.serverhouse 249.189.181.45 2 u 4 128 377 0.218 395.450 371.427[/code]

Pour le moment (je viens de redémarrer ntp), mon serveur est bien synchronisé. Mais je suis certain que si je reviens d’ici quelques jours, j’aurai perdu quelques secondes voire minutes.

Edit : Je viens de mettre à jour Debian et le paquet ntp passe à une version supérieure. Peut-être une amélioration en vue ?[/quote]

  • Les offsets me paraissent énormes compte tenu des pings. De plus les fluctuations des serveurs semblent importantes.
  • Il y a un souci entre les serveurs. Puisque deux serveurs de niveau 2 ont entre eux un décalage énorme de 383. À titre indicatif, cela suffirait pour les exclure du pool ntp.
    Voici ce que j’obtiens sur un de mes serveurs NTP (il est dans le pool)

[code]$ ntpq -p
remote refid st t when poll reach delay offset jitter

*xxxxxxxxxxxxxx .TS-4. 1 u 782 1024 377 39.079 -0.194 6.323
xxxxxxxxxxxx ??? 2 u 406 1024 377 46.905 -0.534 1.259
+xxxxxxxxxxxxxxx xxxxxxxxxx 2 u 344 1024 377 43.078 -0.097 8.063
[/code]
Tu peux noter que le ping n’est pas fameux (40) mais que cela suffit à une bonne synchro.

Je te suggère de diminuer le nombre de serveurs de référence (3 suffisent, ton dernier serveur est plus que douteux) et de prendre des serveurs du pool Français. J’ai du mal à comprendre comment un serveur NTP peut dériver à ce point. Les deux seules fois où ça m’est arrivé sont des plantages de l’horloge RTC (sans doute régulièrement mise à jour). Peut être est ce du à une surcharge réseau. Auquel cas une gestion des priorités (dispositif QoS) serait une bonne idée.

@fran.b ntpdate sur un serveur de temps permet de mettre à l’heure la machine en une fois quand l’écart est trop grand alors que ntp va prendre beaucoup plus de temps,ensuite l’offset devient grosso modo le même pour les serveurs qui sont choisis,ceux qui sont marqués + ou * ,du moins c’est ainsi que je comprends les choses et ma machine est toujours à l’heure.Toute explication supplémentaire est la bienvenue.

ntp est fait pour que des machines restent synchronisées. Dès qu’une machine est allumée plus d’une jouyrnée, ntp s’impose.
ntpdate ne sert dans la pratique que pour initialiser un servbeur de temps (sur ceux que je gère, je l’ai fait une seule fois il y a donc 2 ans au plus tôt pour le dernier) puis c’est tout. Si ton horloge RTC déconne, cela peut être utile après un reboot. Mais une dérive de l’horloge alors que ntp tourne est incompréhensible sauf si il y a saturation du réseau au point que le ping reste longtemps supérieur à 400-500ms.

La synchronisation se fait effectivement petit à petit mais une fois que cela est acquis, ça ne bouge plus. Cette synchronisation est très efficace et permet de garantir l’heure avec un delta de l’ordre de «ping/4» (comprendre que offset doit être inférieur à delay/4).

Ici tu as visiblement 4 serveurs dont 2 au moins sont locaux.

Si les 4 serveurs sont locaux, ils se synchronisent mutuellement il n’y a pas de point fixe de référence, dans ce cas il est important d’avoir un serveur de référence (stratum 1) sur lequel se synchronisent les autres machines. La structure doit être arborescente: A se synchronise sur B qui se synchronise sur C qui se synchronise sur A peut donner des dérives.

Je m’étonne vraiment que tu ais 3 serveurs stratum 2 avec des écarts de l’ordre de 300ms. Ce dernier serveur est pathologique et te met la pagaille de toute façon.

Bonjour à vous deux, merci de votre aide.
Je reviens après quelques jours et j’ai déjà pris plus d’une heure de retard…

NTPd semblait s’être arrêté de lui-même puisque lorsque j’ai tenté de redémarrer le service, j’ai eu un beau « […] Stopping NTP server: ntpdstart-stop-daemon: warning: failed to kill 30451: No such process ».

J’ai tenté d’ajouter quelques serveurs dans le fichier /etc/ntp.conf, sans conviction que ça fonctionne réellement. Et je suis obligé d’attendre quelques jours pour pouvoir constater un décalage.

BrasDeMehldau

bonjour.

que dit:

hwclock --show ( commande en root )

Bonjour avram,
Voici le retour de la commande que tu m’as demandée :

# sudo hwclock --show lun. 16 févr. 2015 14:15:44 CET -0.703570 secondes

Ce qui correspond à l’heure UTC.

Néanmoins, depuis que j’ai modifié un peu ma configuration, j’ai l’impression qu’il n’y a pas de décalage. À voir si ça tient dans la durée ou si j’aurai bientôt un nouveau décalage.

BrasDeMehldau

[quote=“BrasDeMehldau”]Bonjour à vous deux, merci de votre aide.
Je reviens après quelques jours et j’ai déjà pris plus d’une heure de retard…

NTPd semblait s’être arrêté de lui-même puisque lorsque j’ai tenté de redémarrer le service, j’ai eu un beau « […] Stopping NTP server: ntpdstart-stop-daemon: warning: failed to kill 30451: No such process ».

J’ai tenté d’ajouter quelques serveurs dans le fichier /etc/ntp.conf, sans conviction que ça fonctionne réellement. Et je suis obligé d’attendre quelques jours pour pouvoir constater un décalage.

BrasDeMehldau[/quote]
Regarde les fichiers daemon.log sous /var/log ainsi que les syslog pour voir la raison du crash de ntp. Je soupconne un souci du module RTC