[ntp] Écart de l'heure constaté sur 2 machines avec la même configuration

[Francois Lafont]

Bonjour à tous,

J'ai deux machines, une Squeeze et l'autre une Ubuntu Precise. Ce sont des OS différents mais je pense que, dans le cas présent, ça n'a pas d'importance. Sur les deux machines, j'ai installé le paquet ntp et j'ai mis la même configuration dans le fichier /etc/ntp.conf à savoir :

------------------------------------------------------------------
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

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

# You do need to talk to an NTP server or two (or three).
server ntp1.proxad.net


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
------------------------------------------------------------------

J'ai redémarré le service ntp sur les deux machines après modification de la configuration.

Au départ, juste après le redémarrage des services ntp, j'ai bien mes deux machines qui ont la même heure (à une dizaine de secondes près). Mais au bout d'un certain temps (pas très longtemps, à peine une heure ou deux), je me retrouve avec un décalage de l'heure entre les deux machines qui peut atteindre 20s voire 30s.

J'ai tenté aussi de mettre dans la configuration de ntp (des deux machines) 4 serveurs de temps (par exemple avec les {0,1,2,3}.fr.pool.ntp.org) mais j'ai aussi le même phénomène qui finit par se produire.

Dans mon esprit, ntp est un truc assez précis et je pensais que j'aurais deux machines à la même heure à la seconde près les doigts dans le nez.

Est-ce que j'en demande trop ?
Ou bien je ne fais pas ce qu'il faut au niveau de la configuration ?

Pour info, sur la Squeeze j'ai :

~# ntpd --version
ntpd - NTP daemon program - Ver. 4.2.6p2

et sur la Precise j'ai :
~# ntpd --version
ntpd - NTP daemon program - Ver. 4.2.6p3
ntpd 4.2...@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1)

Merci d'avance pour votre aide.

--
François Lafont

[Christophe PEREZ]

Le Fri, 10 May 2013 21:10:10 +0200, Francois Lafont a écrit :

> à une dizaine de secondes près

C'est déjà considérablement énorme comme différence.
Tu es sur que les 2 se synchronisent bien avec le serveur ntp ?
ntpq -p sur chaque machine pour voir.

De plus, je ne sais pas pour tes distrib, mais sous gentoo, il y a 2
services à lancer au boot, ntp-client qui synchronise ponctuellement la
machine, et ntpd qui maintient cette synchro.
Parce que si j'ai bien compris, quand ntpd tombe sur un écart trop grand
(mais tout de même pas de cet ordre) il ne synchronise pas.

Bon, je me ferai sans doute corriger par les experts, mais peut-être que
ça peut t'aider à avancer.

NB : ça serait bien que ton soft de news coupe les lignes à une longueur
raisonnable.

[Francois Lafont]

Le 10/05/2013 21:31, Christophe PEREZ a écrit :

>> à une dizaine de secondes près
>
> C'est déjà considérablement énorme comme différence.
> Tu es sur que les 2 se synchronisent bien avec le serveur ntp ?
> ntpq -p sur chaque machine pour voir.

Oui, c'est le même serveur, mais apparemment sur la Squeeze le synchronisation ne se fait pas.

~# ntpq -pn # sur la Ubuntu
remote refid st t when poll reach delay offset jitter
==============================================================================
*212.27.60.17 91.121.154.174 3 u 118 512 377 20.227 -32.040 8.663

~# ntpq -pn # sur la Squeeze
remote refid st t when poll reach delay offset jitter
==============================================================================
212.27.60.17 91.121.154.174 3 u 49 64 7 20.585 165155. 1913.83

Sur la Squeeze, donc, pas de synchronisation. C'est curieux ?

Au fait, dans "offset" c'est quoi l'unité ? Des millisecondes ?

> De plus, je ne sais pas pour tes distrib, mais sous gentoo, il y a 2
> services à lancer au boot, ntp-client qui synchronise ponctuellement la
> machine, et ntpd qui maintient cette synchro.

Sur Squeeze ou Precise, le seul service ntp* que j'ai est ntp, du coup ça ne me dit rien cette histoire de ntp-client.

> Parce que si j'ai bien compris, quand ntpd tombe sur un écart trop grand
> (mais tout de même pas de cet ordre) il ne synchronise pas.

Ah, c'est peut-être ça qui ce produit alors sur ma Squeeze ? Mais dans ce cas, il faut faire comment pour que ça tourne tout seul sans intervention humaine ? Car sur mes deux distributions je n'ai pas le "ntp-client" dont tu parles.

Merci de ton aide.

> NB : ça serait bien que ton soft de news coupe les lignes à une longueur
> raisonnable.

Ah, je l'avais paramétré ainsi auparavant mais avec les mobiles etc. ça formait coupures de lignes au mauvais endroit alors maintenant j'ai enlevé ce réglage. Je ne sais pas trop ce qui est le mieux.

--
François Lafont

[Christophe PEREZ]

Le Fri, 10 May 2013 22:49:00 +0200, Francois Lafont a écrit :

> Oui, c'est le même serveur,

Ce n'était pas ma question. Je me(te) demandais s'il n'y aurait pas un
"blocage" genre firewall qui empêcherait une des 2 machines de contacter
le serveur ntp, donc de s'y synchroniser.

> mais apparemment sur la Squeeze le
> synchronisation ne se fait pas.

Même réglage de date / fuseau hoaire sur les 2 machines ?
Que donne la commande date ?

> Au fait, dans "offset" c'est quoi l'unité ? Des millisecondes ?

Je ne sais pas/plus. Je ne suis vraiment pas un expert en la matière.

> Sur Squeeze ou Precise, le seul service ntp* que j'ai est ntp, du coup
> ça ne me dit rien cette histoire de ntp-client.

Oui, mais j'ai bien dit "sous gentoo". CE que je voulais dire par là,
c'était qu'il y avait un mécanisme pour mettre la machine à l'heure AVANT
de lancer un service de synchronisation permanente.
A la limite, pour tes tests, mets ta machine à l'heure manuellement comme
l'est l'autre machine, avec le bon fuseau et tout et tout, avant de
lancer ntpd.

>> Parce que si j'ai bien compris, quand ntpd tombe sur un écart trop
>> grand (mais tout de même pas de cet ordre) il ne synchronise pas.
>
> Ah, c'est peut-être ça qui ce produit alors sur ma Squeeze ? Mais dans
> ce cas, il faut faire comment pour que ça tourne tout seul sans
> intervention humaine ? Car sur mes deux distributions je n'ai pas le
> "ntp-client" dont tu parles.

Il faudra faire des recherches dans ce sens pour cette distribution. Mais
je ne saurai t'en dire plus.

>> NB : ça serait bien que ton soft de news coupe les lignes à une
>> longueur raisonnable.
>
> Ah, je l'avais paramétré ainsi auparavant mais avec les mobiles etc. ça
> formait coupures de lignes au mauvais endroit alors maintenant j'ai
> enlevé ce réglage. Je ne sais pas trop ce qui est le mieux.

Mouais, mais bon, scroller 3 ou 4 pages horizontalement pour lire
entièrement tes lignes, je t'avoue que je ne le ferai pas souvent ;).

[Benoit Izac]

Bonjour,

le 10/05/2013 � 23:30, Christophe PEREZ a �crit dans le message
<kmjotc$nb8$1...@serveur2.novazur.fr> :

>> Au fait, dans "offset" c'est quoi l'unit� ? Des millisecondes ?

Je dirai plut�t des microsecondes

>>> Parce que si j'ai bien compris, quand ntpd tombe sur un �cart trop
>>> grand (mais tout de m�me pas de cet ordre) il ne synchronise pas.
>>
>> Ah, c'est peut-�tre �a qui ce produit alors sur ma Squeeze ? Mais dans
>> ce cas, il faut faire comment pour que �a tourne tout seul sans

>> intervention humaine ? Car sur mes deux distributions je n'ai pas le
>> "ntp-client" dont tu parles.
>
> Il faudra faire des recherches dans ce sens pour cette distribution. Mais
> je ne saurai t'en dire plus.

Le programme s'appelle ntpdate. De nos jours (ntp-4.x.x), on utilise
ntpd avec ��-q��, qui est �quivalent � ntpdate, ou on le lance avec
��-g�� qui fait automatiquement la correction si n�cessaire.

--
Benoit Izac

[Francois Lafont]

Le 10/05/2013 23:30, Christophe PEREZ a écrit :

>> Oui, c'est le même serveur,
>
> Ce n'était pas ma question. Je me(te) demandais s'il n'y aurait pas un
> "blocage" genre firewall qui empêcherait une des 2 machines de contacter
> le serveur ntp, donc de s'y synchroniser.

Je ne pense pas (sans en être sûr) car :
- Les deux machines sont des VM de test Virtualbox chez moi derrière ma Freebox.
- Toutes les deux avec une interface bridgée sur le eth0 de l'hôte physique.
- Aucune règles iptables en place car sur les 2 VM car iptables-save ne me renvoie rien.
- Et pourtant la ubuntu, elle, semble se synchroniser sans problème.

>> Au fait, dans "offset" c'est quoi l'unité ? Des millisecondes ?
>
> Je ne sais pas/plus. Je ne suis vraiment pas un expert en la matière.

Ce sont des bien millisecondes d'après mes recherches sur le Web.

>> Sur Squeeze ou Precise, le seul service ntp* que j'ai est ntp, du coup
>> ça ne me dit rien cette histoire de ntp-client.
>
> Oui, mais j'ai bien dit "sous gentoo". CE que je voulais dire par là,
> c'était qu'il y avait un mécanisme pour mettre la machine à l'heure AVANT
> de lancer un service de synchronisation permanente.
> A la limite, pour tes tests, mets ta machine à l'heure manuellement comme
> l'est l'autre machine, avec le bon fuseau et tout et tout, avant de
> lancer ntpd.

Testé sur la Squeeze qui ne veut pas se synchroniser :

-----------------------
service ntp stop
apt-get install ntpdate
ntpdate ntp1.proxad.net # synchronisation manuelle.

# Ça me renvoie ça :
# 10 May 23:46:07 ntpdate[9099]: step time server 88.191.225.6 offset 48.996949 sec

# J'en fait plusieurs pour bien insister. Je m'arrête à celle qui me renvoie :
# 10 May 23:50:08 ntpdate[9197]: adjust time server 212.27.60.17 offset 0.114611 sec

# Là, je me dis on est bien.
service ntp start
-----------------------

Et ben, non ça ne prend pas :

~# ntpq -pn

remote refid st t when poll reach delay offset jitter
==============================================================================

212.27.60.17 91.121.154.174 3 u 8 64 1 20.576 324.590 0.000

L'offset est relativement raisonnable. Mais quelques minutes plus tard :

~# ntpq -pn

remote refid st t when poll reach delay offset jitter
==============================================================================

212.27.60.17 91.121.154.174 3 u 33 64 3 20.725 1542.04 1217.45

Ça repart en sucette... :) Et je n'ai toujours pas ma petite "*" en face de l'ip du serveur ntp.
Alors que sur Ubuntu oui.

Je n'ai de souci de timezone etc. il me semble :

~# date # sur la Ubuntu
vendredi 10 mai 2013, 23:58:27 (UTC+0200)

~# date # sur la Squeeze
vendredi 10 mai 2013, 23:58:18 (UTC+0200)

(Les deux commandes ont été lancées au même moment à 1 seconde près.)

>>> Parce que si j'ai bien compris, quand ntpd tombe sur un écart trop
>>> grand (mais tout de même pas de cet ordre) il ne synchronise pas.
>>
>> Ah, c'est peut-être ça qui ce produit alors sur ma Squeeze ? Mais dans
>> ce cas, il faut faire comment pour que ça tourne tout seul sans
>> intervention humaine ? Car sur mes deux distributions je n'ai pas le
>> "ntp-client" dont tu parles.
>
> Il faudra faire des recherches dans ce sens pour cette distribution. Mais
> je ne saurai t'en dire plus.

J'ai l'impression finalement que le problème va au delà de ça en fait...

> Mouais, mais bon, scroller 3 ou 4 pages horizontalement pour lire
> entièrement tes lignes, je t'avoue que je ne le ferai pas souvent ;).

Ah mince désolé. Chez moi, mon lecteur (Thunderbird en fait) coupe les
lignes en fonction de la largeur de la fenêtre, ce n'est pas le cas chez
toi ?

J'ai fait des efforts sur ce message pour que tu n'aies pas à scroller. :)

Ah oui, un autre point qui m'a fait pencher pour enlever les coupures de
lignes, c'est quand on cite du code et que certaines lignes sont coupées.
C'est un peu pénible parfois je trouve.

PS : le temps que je finisse d'écrire ce message, voilà où en est ma
pauvre Squeeze qui n'en fait qu'à sa tête :

~# ntpq -pn

remote refid st t when poll reach delay offset jitter
==============================================================================

212.27.60.17 91.121.154.174 3 u 35 64 377 19.974 14624.8 5281.46

J'avais un offset de 324.590 au début du message. Cela dit, je tape lentement. :)

--
François Lafont

[Benoit Izac]

Dans le message <87haiac...@izac.org>, le 11/05/2013 � 00:08, j'ai
�crit :

>>> Au fait, dans "offset" c'est quoi l'unit� ? Des millisecondes ?
>
> Je dirai plut�t des microsecondes

Pas bon de faire un test juste apr�s s'�tre connect� au wifi. J'avais
des valeurs entre 900 et 1000, ce qui ne pouvait pas �tre des
millisecondes (la pr�cision de ntp est plus proche de la milliseconde
que de la seconde). Maintenant, c'est bien des millisecondes. ;-)

--
Benoit Izac

[Francois Lafont]

Le 11/05/2013 00:08, Benoit Izac a écrit :

> Le programme s'appelle ntpdate. De nos jours (ntp-4.x.x), on utilise

> ntpd avec « -q », qui est équivalent à ntpdate, ou on le lance avec
> « -g » qui fait automatiquement la correction si nécessaire.

J'ai tenté aussi de stopper le service ntp, de faire un petit « ntpd -gq »
qui me remet bien une heure correcte mais ensuite quand je redémarre le
service au départ j'ai un offset raisonnable et puis ça augmente petit à
petit comme montré précédemment.

J'ai tenté un petit tcpdump, j'ai bien Squeeze qui régulièrement envoie
une requête [udp:123] vers le serveur ntp paramétré dans ntp.conf et
celui-ci qui répond dans la foulée. Par contre, je suis incapable de
comprendre le contenu des paquets en question (peut-être que la réponse
du serveur distant est « fous-moi la paix :) »).

Je ne comprends pas pourquoi la synchronisation ne se fait pas...

Sur cette Squeeze récalcitrante, j'ai bien ntpd qui est lancé avec l'option -g :

~# ps -u ntp -o 'pid,command'
PID COMMAND
11240 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:106

--
François Lafont

[Christophe PEREZ]

Le Sat, 11 May 2013 00:08:53 +0200, Francois Lafont a écrit :

> - Aucune règles iptables en place car sur les 2 VM car iptables-save ne
> me renvoie rien.

Dans ce cas, effectivement.

> Je n'ai de souci de timezone etc. il me semble :
>
> ~# date # sur la Ubuntu vendredi 10 mai 2013, 23:58:27 (UTC+0200)
> ~# date # sur la Squeeze vendredi 10 mai 2013, 23:58:18 (UTC+0200)

Effectivement...

> Ah mince désolé. Chez moi, mon lecteur (Thunderbird en fait) coupe les
> lignes en fonction de la largeur de la fenêtre, ce n'est pas le cas chez
> toi ?

En fait si, mais comme je ne l'avais pas utilisé pendant plusieurs
années, j'avais oublié cette option ;)

> Ah oui, un autre point qui m'a fait pencher pour enlever les coupures de
> lignes, c'est quand on cite du code et que certaines lignes sont
> coupées.
> C'est un peu pénible parfois je trouve.

C'est vrai.

> J'avais un offset de 324.590 au début du message. Cela dit, je tape
> lentement. :)

Franchement, aucune piste ne me vient à l'esprit pour l'instant.
Désolé.

[Pascal]

Le 10/05/2013 21:10, Francois Lafont a écrit :
> Bonjour à tous,
>
> J'ai deux machines, une Squeeze et l'autre une Ubuntu Precise. Ce sont des OS différents mais je pense que, dans le cas présent, ça n'a pas d'importance. Sur les deux machines, j'ai installé le paquet ntp et j'ai mis la même configuration dans le fichier /etc/ntp.conf à savoir :
>

Pas assez spécialiste pour répondre à ta question.
J'utilise de mon côté openntp

[Damien Wyart]

* Francois Lafont <francoi...@nospam.invalid>
in fr.comp.os.linux.configuration:
> [...] J'ai red�marr� le service ntp sur les deux machines apr�s
> modification de la configuration.

> Au d�part, juste apr�s le red�marrage des services ntp, j'ai bien mes
> deux machines qui ont la m�me heure (� une dizaine de secondes pr�s).
> Mais au bout d'un certain temps (pas tr�s longtemps, � peine une heure
> ou deux), je me retrouve avec un d�calage de l'heure entre les deux

> machines qui peut atteindre 20s voire 30s.

Visiblement sur l'une des deux machines, ntpd n'arrive pas � �lire de
serveur ntp pour servir de r�f�rence et du coup n'effectue pas de
synchronisation ; c'est peut-�tre juste l'horloge locale qui est trop
mauvaise (d�rive trop forte) et que ntpd refuse d'utiliser. Pour essayer
d'en conna�tre la raison tu peux te baser sur ces documents (en Anglais,
j'esp�re que �a peut convenir), en gros �a utilise ntpq (et
�ventuellement ntpdc) avec des options particuli�res :

http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
http://www.eecis.udel.edu/~mills/ntp/html/debug.html

Sinon il y a l'option -d � ntpd mais elle est indisponible dans
debian :-(

--
DW

[JM Company]

Francois Lafont wrote:

> Bonjour à tous,
>

Salut....... Est ce que les appels au serveur NTP sont envoyés
au même moment sur les deux machines ? Parce que si c'est le cas, le
serveur ne répondra pas à l'une des deux ! En fait il ne répondra pas à
celle qui arrive juste en deuxième. Et cela parce que pour lui il s'agit
de la même machine (même adresse IP) !!!

Il faut alors décaler les appels dans le temps sur tes deux
machines!

JM

[Erwan David]

Damien Wyart <damien...@free.fr> �crivait�:

�a peut �tre aussi que l'horloge est trop d�cal�e et que ntpd renonce.

On peut voir �a en relan�ant ntpd et en regardant les logs

> Sinon il y a l'option -d � ntpd mais elle est indisponible dans
> debian :-(

Sous debian on peut installer le paquet ntpdate qui au boot sera ex�cut�
avant le lancement de ntpd pour donner une heure correcte � la machine,
ntpd se chargeant ensuite de la maintenir


--
Les simplifications c'est trop compliqu�

[Bruno Ducrot]

On 2013-05-11, JM Company wrote:
> Francois Lafont wrote:
>
>> Bonjour ￜ tous,
>>
>
> Salut....... Est ce que les appels au serveur NTP sont envoyï¿œs
> au mï¿œme moment sur les deux machines ? Parce que si c'est le cas, le
> serveur ne rￜpondra pas ￜ l'une des deux ! En fait il ne rￜpondra pas ￜ
> celle qui arrive juste en deuxiï¿œme. Et cela parce que pour lui il s'agit
> de la mï¿œme machine (mï¿œme adresse IP) !!!
>
> Il faut alors dï¿œcaler les appels dans le temps sur tes deux
> machines!

Cela aurait pu ï¿œtre effectivement un problï¿œme, sauf qu'en fait
le seul problï¿œme avec NTP lorsque l'on utilise un NAT se pose
pour l'authentification, sjmsb, ce qui n'est pas le cas ici.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?

[JM Company]

Bruno Ducrot wrote:

> On 2013-05-11, JM Company wrote:
>> Francois Lafont wrote:
>>

>>> Bonjour à tous,
>>>
>>
>> Salut....... Est ce que les appels au serveur NTP sont envoyés
>> au même moment sur les deux machines ? Parce que si c'est le cas, le
>> serveur ne répondra pas à l'une des deux ! En fait il ne répondra pas à
>> celle qui arrive juste en deuxième. Et cela parce que pour lui il s'agit
>> de la même machine (même adresse IP) !!!
>>
>> Il faut alors décaler les appels dans le temps sur tes deux
>> machines!
>
> Cela aurait pu être effectivement un problème, sauf qu'en fait
> le seul problème avec NTP lorsque l'on utilise un NAT se pose

> pour l'authentification, sjmsb, ce qui n'est pas le cas ici.
>
> A plus,
>

Pas besoin d'authentification ! Le serveur ne répond pas pour des
requettes quasi simultanées d'une même IP....... J'ai eu ce problème,
il y a quelque années, avec 4 serveurs derrière un NAT !


JM

[Nicolas George]

JM Company , dans le message <518e1a35$0$2103$426a...@news.free.fr>, a
�crit�:
> Pas besoin d'authentification ! Le serveur ne r�pond pas pour des
> requettes quasi simultan�es d'une m�me IP....... J'ai eu ce probl�me,
> il y a quelque ann�es, avec 4 serveurs derri�re un NAT !

Sauf erreur de ma part, si le serveur ne r�pond pas, le client r�essaiera
plus t�t que si le serveur r�pond, ce qui fait qu'� part la premi�re fois,
les requ�tes seront facilement d�phas�es.

�videmment, le nombre de requ�tes va �tre multipli� par le nombre de
clients, ce qui peut d�plaire aux serveurs. Il vaudrait mieux installer un
serveur local.

[JM Company]

Nicolas George wrote:

> JM Company , dans le message <518e1a35$0$2103$426a...@news.free.fr>, a

> écrit :

>> Pas besoin d'authentification ! Le serveur ne répond pas pour des
>> requettes quasi simultanées d'une même IP....... J'ai eu ce problème,

>> il y a quelque années, avec 4 serveurs derrière un NAT !
>
> Sauf erreur de ma part, si le serveur ne répond pas, le client réessaiera
> plus tôt que si le serveur répond, ce qui fait qu'à part la première fois,
> les requêtes seront facilement déphasées.
>

Sauf si l'on n'utilise pas de daemon local et que les requettes
sont faites via le cron et à heure fixe !!

JM

[Bruno Ducrot]

On 2013-05-11, JM Company wrote:

> Nicolas George wrote:
>
>> JM Company , dans le message <518e1a35$0$2103$426a...@news.free.fr>, a

>> ï¿œcrit :
>>> Pas besoin d'authentification ! Le serveur ne rï¿œpond pas pour des
>>> requettes quasi simultanï¿œes d'une mï¿œme IP....... J'ai eu ce problï¿œme,
>>> il y a quelque annï¿œes, avec 4 serveurs derriï¿œre un NAT !
>>
>> Sauf erreur de ma part, si le serveur ne rï¿œpond pas, le client rï¿œessaiera
>> plus tￜt que si le serveur rￜpond, ce qui fait qu'ￜ part la premiￜre fois,
>> les requï¿œtes seront facilement dï¿œphasï¿œes.

>>
>
> Sauf si l'on n'utilise pas de daemon local et que les requettes

> sont faites via le cron et ￜ heure fixe !!

Vous avez raison pour ce cas en particulier. Par contre, l'OP a bien
prￜcisￜ qu'il utilisait justement ntpd afin de syncroniser ses machines
virtuelles.

[Francois Lafont]

Bonjour,

Merci à tous pour vos réponses.

En fait, il s'est passé quelque chose de bien frustrant aujourd'hui : je démarre les VM sans avoir touché à quoi que ce soit depuis hier soir et bien sûr, comme par hasard, les deux VM se synchronisent parfaitement sur le même serveur.

Très honnêtement, je ne comprends pas ce qu'il s'est passé. Par rapport à l'hypothèse des requêtes simultanées, je ne pense pas que ça soit ça car 1) avec les tcpdump d'hier sur les 2 VM je me rappelle bien les requêtes n'étaient pas simultanées et 2) sur la Squeeze récalcitrante j'avais aussi tenté hier soir de prendre comme serveurs distants les {0,1,2,3,4}.fr.pool.ntp.org sans succès non plus (j'ai remis ensuite le même serveur distant dans la conf des deux VM avant de les éteindre).

Merci à Damien pour ses 2 liens qui m'ont l'air très intéressants :
http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
http://www.eecis.udel.edu/~mills/ntp/html/debug.html

Bon, ça va être dur d'élucider le problème maintenant. Si jamais ça se reproduit, je reviendrai à la charge sur ce fil armé des commandes citées dans le premier lien de Damien. Évidemment si vous avez des idées de manips dans l'immédiat, je suis preneur mais maintenant que le problème a disparu, je crains qu'il n'y ait pas grand chose à faire pour le moment.

--
François Lafont

[f...@obs-besancon.fr]

Francois Lafont <francoi...@nospam.invalid> wrote:
> Bonjour,
>
> Merci � tous pour vos r�ponses.
>
> En fait, il s'est pass� quelque chose de bien frustrant aujourd'hui :
> je d�marre les VM sans avoir touch� � quoi que ce soit depuis hier
> soir et bien s�r, comme par hasard, les deux VM se synchronisent
> parfaitement sur le m�me serveur.
>
> Tr�s honn�tement, je ne comprends pas ce qu'il s'est pass�. Par
> rapport � l'hypoth�se des requ�tes simultan�es, je ne pense pas
> que �a soit �a car 1) avec les tcpdump d'hier sur les 2 VM je me
> rappelle bien les requ�tes n'�taient pas simultan�es et 2) sur la
> Squeeze r�calcitrante j'avais aussi tent� hier soir de prendre comme
> serveurs distants les {0,1,2,3,4}.fr.pool.ntp.org sans succ�s non
> plus (j'ai remis ensuite le m�me serveur distant dans la conf des
> deux VM avant de les �teindre).
>
> Merci � Damien pour ses 2 liens qui m'ont l'air tr�s int�ressants :
> http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
> http://www.eecis.udel.edu/~mills/ntp/html/debug.html
>
> Bon, �a va �tre dur d'�lucider le probl�me maintenant. Si jamais
> �a se reproduit, je reviendrai � la charge sur ce fil arm� des
> commandes cit�es dans le premier lien de Damien. �videmment si vous
> avez des id�es de manips dans l'imm�diat, je suis preneur mais
> maintenant que le probl�me a disparu, je crains qu'il n'y ait pas
> grand chose � faire pour le moment.

Bonjour,

C'est un peu en retard et c'est juste des pistes :

ntp �value, ajuste et maintient constamment l'�cart de
fr�quence de l'horloge syst�me dans un fichier (par d�faut
/etc/ntp.drift). Une fois ntpd chaud (ce qui peut prendre du
temps, en heures), ntp.drift est aussi stable que possible
et est utilis� pour piloter la fr�quence de l'horloge syst�me.

Si la fr�quence de cette horloge syst�me est trop dans les choux
(� cause par exemple d'une horloge mat�rielle pourrie),
la pente peut �tre trop raide pour les braquets par d�faut
du d�mon ntp, qui va p�daler un moment en reculant avant de jeter
le v�lo dans le ravin (c'est tr�s imag�...)

Qu'est-ce qu'il y a dans /etc/ntp.drift maintenant par exemple ?

VM c'est pour "virtual machine" ? Si oui, ce n'est potentiellement
pas tout � fait innocent non plus, � v�rifier.

--
Fran�ois Meyer

[Francois Lafont]

Bonsoir,

Le 23/05/2013 12:25, f...@obs-besancon.fr a écrit :

> C'est un peu en retard

Pas de souci. Chacun son rythme sur les forums. ;-)
En plus j'ai ma Squeeze qui à nouveau ne veut plus se synchroniser.

> et c'est juste des pistes :
>

> ntp évalue, ajuste et maintient constamment l'écart de
> fréquence de l'horloge système dans un fichier (par défaut

> /etc/ntp.drift). Une fois ntpd chaud (ce qui peut prendre du
> temps, en heures), ntp.drift est aussi stable que possible

> et est utilisé pour piloter la fréquence de l'horloge systéme.
>
> Si la fréquence de cette horloge système est trop dans les choux
> (à cause par exemple d'une horloge matérielle pourrie),
> la pente peut être trop raide pour les braquets par défaut
> du démon ntp, qui va pédaler un moment en reculant avant de jeter
> le vélo dans le ravin (c'est très imagé...)

>
> Qu'est-ce qu'il y a dans /etc/ntp.drift maintenant par exemple ?

Sur ma Squeeze, le fichier n'est pas au même endroit et j'ai ça :

~# cat /var/lib/ntp/ntp.drift
500.000

Et il signifie quoi ce 500.000 exactement ?

> VM c'est pour "virtual machine" ?

Oui, des VM Virtualbox toutes bêtes.

> Si oui, ce n'est potentiellement

> pas tout à fait innocent non plus, à vérifier.

Ah... peut-être bien. Là, avec Virtualbox, j'ai de la full virtualisation il me semble alors je me dis que le souci ne vient pas de là mais je me trompe peut-être.

En tout cas, ma Squeeze repart dans les choux :

~# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================

212.27.60.17 91.121.154.174 3 u 48 64 377 19.944 10333.7 5695.79

Fort du lien que m'a passé Damien (http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/), j'essaye d'en savoir plus :

---------------------------------------------------------------
~# ntpq
ntpq> as

ind assid status conf reach auth condition last_event cnt
===========================================================
1 24386 9024 yes yes none reject reachable 2

ntpq> rv 24386
associd=24386 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=webcgi1-g20.free.fr, srcport=123, dstadr=192.168.0.20,
dstport=123, leap=00, stratum=3, precision=-20, rootdelay=5.310,
rootdisp=52.856, refid=91.121.154.174,
reftime=d552470c.d996f9af Thu, May 30 2013 23:45:48.849,
rec=d5524af3.d72c53cf Fri, May 31 2013 0:02:27.840, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0,
flash=400 peer_dist, keyid=0, offset=11619.969, delay=23.917,
dispersion=0.961, jitter=5700.795, xleave=2.215,
filtdelay= 23.92 19.94 20.46 19.13 20.00 20.14 22.95 20.87,
filtoffset= 11619.9 10333.7 9086.15 7838.51 6551.21 5244.38 3937.53 2689.17,
filtdisp= 0.02 1.01 1.97 2.93 3.92 4.92 5.93 6.89
ntpq>
---------------------------------------------------------------

Et là j'ai le même souci que celui décrit dans le lien : « "flash=400 peer_dist". This flash code corresponds to "distance threshold exceeded". »

Ok, j'ai dépassé un seuil d'une certaine distance, mais une distance entre quoi et quoi ?

Au départ, je pensais que cette distance était l'écart entre mon heure et celle du serveur ntp sur lequel je souhaite me synchroniser mais je ne pense pas finalement que ça soit ça car avant de relancer ntpd (et qu'il ne parte en cacahuète), j'ai bien fait :

---------------------------------------------------------------
~# invoke-rc.d ntp stop
Stopping NTP server: ntpd.

~# ntpd -gq
ntpd: time set +18.157637s

~# ntpd -gq # j'en remets une couche
ntpd: time set +0.199055s

~# invoke-rc.d ntp start
Starting NTP server: ntpd.
---------------------------------------------------------------

Donc j'avais eu la gentillesse de relancer ntpd alors que le temps était déjà synchronisé.

Bref, je ne comprends pas trop la raison qui fait que la synchronisation ne se fait pas et du coup je ne sais pas comment y remédier. Peut-être que certains parmi vous sauront interpréter toutes les valeurs ci-dessus (ntp m'a l'air d'être un protocole à pas piquer des hannetons ;-)).

Merci d'avance pour vos lumières.


--
François Lafont

[Lucas Levrel]

Le 31 mai 2013, Francois Lafont a ï¿œcrit :

> Et lￜ j'ai le mￜme souci que celui dￜcrit dans le lien : ￜ "flash=400

> peer_dist". This flash code corresponds to "distance threshold

> exceeded". ￜ
>
> Ok, j'ai dￜpassￜ un seuil d'une certaine distance, mais une distance

> entre quoi et quoi ?

delay trop grand ? As-tu essayￜ diffￜrents serveurs ? (Dans ma conf j'ai
fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec un
ￜￜdelayￜￜ 2.404).

--
LL

[Damien Wyart]

Bonjour,

Je vais essayer de répondre, et ça risque d'être un peu long :)

En très résumé, ce qui pose problème c'est qu'il s'agit de machines
virtuelles ; parfois on n'a pas de problème (ça dépend notamment de
l'outil utilisé pour virtualiser, par exemple avec Xen ça se passe bien
en général, et ça dépend aussi du matériel), mais il est assez fréquent
que NTP ne soit pas utilisable dans ce contexte.

Je vais donner d'autres détails, mais je pense que le plus simple est de
renoncer à NTP dans les VMs (mais le conserver sur la machine physique
pour que l'horloge système soit fiable) et d'utiliser les "Vbox Guest
Additions" pour effectuer le synchronisation des VMs sur la machine
physique. Normalement tu as juste à installer ça et cela doit suffire
(on peut tuner comme indiqué plus loin mais pas sûr du tout que ça soit
nécessaire dans ton cas).

* Francois Lafont <francoi...@nospam.invalid>
in fr.comp.os.linux.configuration:

> Sur ma Squeeze, le fichier n'est pas au même endroit et j'ai ça :

> ~# cat /var/lib/ntp/ntp.drift
> 500.000

> Et il signifie quoi ce 500.000 exactement ?

Il s'agit du décalage de fréquence entre la machine surveillée par ntpd
et la source de référence ; c'est exprimé en PPM, voir les détails ici :
http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

> > VM c'est pour "virtual machine" ?

> Oui, des VM Virtualbox toutes bêtes.

> Ah... peut-être bien. Là, avec Virtualbox, j'ai de la full
> virtualisation il me semble alors je me dis que le souci ne vient pas
> de là mais je me trompe peut-être.

Il y a de très fortes chances que le problème vienne de là ; une
recherche Google donne énormément de choses (à la fois en nombre de
résultats, et certains résultats sont particulièrement verbeux) :

http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
https://www.virtualbox.org/ticket/3135 (particulièrement long !)
https://www.virtualbox.org/ticket/3569 (la conclusion qui est je pense la plus simple)
https://forums.virtualbox.org/viewtopic.php?f=1&t=27521 (pareil)
https://lists.ntp.org/pipermail/questions/2011-March/028783.html (encore)
https://lists.ntp.org/pipermail/questions/2011-March/thread.html#28757 (là le thread est vraiment immense et part en troll par moments)
http://log.or.cz/?p=80
http://serverfault.com/questions/106501/what-are-the-limits-of-running-ntp-servers-in-virtual-machines
http://support.ntp.org/bin/view/Support/VMWareNTP
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.
http://www.virtualbox.org/manual/ch09.html#changetimesync (des infos pour tuner la synchro des VMs sur la machine support)
http://stackoverflow.com/questions/117422/how-can-i-resolve-the-drifting-clock-for-my-virtual-machine
http://serverfault.com/questions/56483/how-do-i-stop-the-clock-running-fast-on-a-virtualbox-client-running-ubuntu-8-04
http://askubuntu.com/questions/280421/ubuntu-inside-virtual-machine-ntpd-or-ntpdate-or-to-avoid-clock-drift
http://serverfault.com/questions/365690/best-practices-for-ntp-updating-in-virtualbox-virtual-machines-without-guest-add
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
http://www.vr.org/kb/161/My-server-clock-or-date-and-time-is-wrong-or-drifts.html
http://hydra.geht.net/tino/howto/virtualbox/linux/time/

> filtoffset= 11619.9 10333.7 9086.15 7838.51 6551.21 5244.38 3937.53 2689.17,

Les valeurs sont plutôt mauvais signe (même si je n'ai pas cherché les
détails pour les interpréter) :
https://lists.ntp.org/pipermail/questions/2011-March/028759.html

> Et là j'ai le même souci que celui décrit dans le lien : « "flash=400
> peer_dist". This flash code corresponds to "distance threshold
> exceeded". »

> Ok, j'ai dépassé un seuil d'une certaine distance, mais une distance
> entre quoi et quoi ?

C'est assez compliqué :
http://www.eecis.udel.edu/~mills/ntp/html/select.html

mais au vu des liens précédents, je dirais que c'est un "effet de bord"
du comportement de l'horloge de la VM, qui perturbe ntpd et ses
algorithmes, qui sont prévus pour une horloge "physique" (en VM il
y a une couche "d'émulation"). De plus, sous Linux, plusieurs sources de
temps sont utilisables et n'ont pas le même comportement, en physique
comme en émulé (on le voit dans le PDF VMware que j'ai cité plus haut).

> Au départ, je pensais que cette distance était l'écart entre mon heure
> et celle du serveur ntp sur lequel je souhaite me synchroniser mais je
> ne pense pas finalement que ça soit ça car avant de relancer ntpd (et
> qu'il ne parte en cacahuète), j'ai bien fait :

> ---------------------------------------------------------------
> ~# invoke-rc.d ntp stop
> Stopping NTP server: ntpd.

> ~# ntpd -gq
> ntpd: time set +18.157637s

> ~# ntpd -gq # j'en remets une couche
> ntpd: time set +0.199055s

> ~# invoke-rc.d ntp start
> Starting NTP server: ntpd.
> ---------------------------------------------------------------

Ce qui pose problème n'est pas "l'alignement" de la VM et de la source
NTP mais le fait que la source de temps de la VM n'est pas assez
régulière.

> Bref, je ne comprends pas trop la raison qui fait que la
> synchronisation ne se fait pas et du coup je ne sais pas comment
> y remédier.

Avec les liens cités plus haut, on pourrait être tenté de "bidouiller"
(voir par exemple
http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/ qui
est assez gratiné :-)

- soit sur la clocksource du noyau invité
- soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox
dans ton cas)
- soit sur la config ntpd ("tinker panic 0", élimination de "fudge
127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos
maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné

-> idem, les items de cette liste peuvent être combinés.

Bref, on ne sait plus trop ce que l'on fait, et si ça marche, on ne sait
pas si ça continuera à marcher, et qu'est-ce qui a vraiment fait que ça
marche, et surtout c'est long de tester toutes ces combinaisons qui au
final contournent ou masquent la cause de départ du problème.

Donc en conclusion (comme indiqué en début de ma réponse), je pense que
le plus sage est d'avoir ntpd sur la machine physique, et les outils
Vbox sur les invités qui activeront une synchronisation sur la machine
physique (elle étant synchronisée sur une source fiable), bref on fait
une chaine simple plutôt qu'un enchevêtrement :)

> Peut-être que certains parmi vous sauront interpréter toutes les
> valeurs ci-dessus (ntp m'a l'air d'être un protocole à pas piquer des
> hannetons ;-)).

NTP est en effet très complexe, il existe un ouvrage de 500 pages qui
l'explique en détail :
http://www.amazon.fr/Computer-Network-Time-Synchronization-Protocol/dp/1439814635/

Sans te vexer (je n'aime pas trop reprendre les gens sur ces aspects),
l'expression correcte est "ne pas être piqué des hannetons" :
http://www.cnrtl.fr/definition/hanneton, c'est à dire être remarquable
ou de bonne qualité puisque les hannetons ou autres parasites ne s'y
attaquent pas.)


En espérant avoir aidé...
--
DW

[Damien Wyart]

* Lucas Levrel <lucas....@u-pec.fr>
in fr.comp.os.linux.configuration:
> delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf

> j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec

> un « delay » 2.404).

Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc
ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et
fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe
vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta
config ?

--
DW

[Damien Wyart]

> En très résumé, ce qui pose problème c'est qu'il s'agit de machines
> virtuelles ; parfois on n'a pas de problème (ça dépend notamment de
> l'outil utilisé pour virtualiser, par exemple avec Xen ça se passe
> bien en général, et ça dépend aussi du matériel), mais il est assez
> fréquent que NTP ne soit pas utilisable dans ce contexte.

Lors des premiers échanges, le message de départ n'indiquait pas qu'il
y avait de la virtualisation, et j'avais du rater le message postérieur,
qui le mentionnait.

> > ~# cat /var/lib/ntp/ntp.drift
> > 500.000

> > Et il signifie quoi ce 500.000 exactement ?

> Il s'agit du décalage de fréquence entre la machine surveillée par
> ntpd et la source de référence ; c'est exprimé en PPM, voir les
> détails ici : http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

Et si je ne me trompe pas, 500 est la valeur maximale, qui fait que ntpd
va refuser de superviser l'horloge de la machine.

> Avec les liens cités plus haut, on pourrait être tenté de "bidouiller"
> (voir par exemple
> http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/
> qui est assez gratiné :-)

> - soit sur la clocksource du noyau invité
> - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox
> dans ton cas)
> - soit sur la config ntpd ("tinker panic 0", élimination de "fudge
> 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos
> maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné

> -> idem, les items de cette liste peuvent être combinés.

J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift
(qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de
l'invité est instable, la valeur est parfois relativement faible et
n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les
démarrages suivants.

--
DW

[Damien Wyart]

> > filtoffset= 11619.9 10333.7 9086.15 7838.51 6551.21 5244.38 3937.53 2689.17,

> Les valeurs sont plutôt mauvais signe (même si je n'ai pas cherché les
> détails pour les interpréter) :
> https://lists.ntp.org/pipermail/questions/2011-March/028759.html

Ce sont les 8 valeurs les plus récentes du décalage (en millisecondes)
entre l'horloge locale et l'horloge de référence. Avec un tel décalage
(croissant, en plus), de l'ordre de plusieurs secondes, ntpd ne peut
rien faire pour redresser la barre ; il est prévu pour réaliser des
ajustements très faibles, afin de lisser l'horloge locale le plus
possible...

--
DW

[Erwan David]

Damien Wyart <damien...@free.fr> écrivait :

Non *.pool.ntp.org n'est *pas* un pool de strate 2.

cf http://www.pool.ntp.org/fr/join.html

« Notez qu'il n'est pas requis que votre serveur soit de strate 1 ou 2 :
comme le projet se concentre plus sur la distribution de la charge, il
n'y a aucune raison qu'un strate 3 ou même un strate 4 ne puisse pas
joindre le projet. »

En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur
un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas
sûr qu'il soit de strate 1

--
Les simplifications c'est trop compliqué

[Damien Wyart]

* Erwan David <er...@rail.eu.org> in fr.comp.os.linux.configuration:

> Non *.pool.ntp.org n'est *pas* un pool de strate 2.

> cf http://www.pool.ntp.org/fr/join.html

Ok, je n'avais pas vérifié.

> En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc
> sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne
> suis pas sûr qu'il soit de strate 1

En effet.

--
DW

[Damien Wyart]

> > Avec les liens cités plus haut, on pourrait être tenté de
> > "bidouiller" (voir par exemple
> > http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/
> > qui est assez gratiné :-)

> > - soit sur la clocksource du noyau invité
> > - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox
> > dans ton cas)
> > - soit sur la config ntpd ("tinker panic 0", élimination de "fudge
> > 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos
> > maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné

> > -> idem, les items de cette liste peuvent être combinés.

> J'ajoute une 4e bidouille qui est parfois mentionnée : effacer
> ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme
> l'horloge de l'invité est instable, la valeur est parfois relativement
> faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien
> sur les démarrages suivants.

Une dernière bidouille pour la route, les outils tickadj et adjtimex.
Mais là aussi, c'est de l'ordre du pansement sur une jambe de bois...

--
DW

[Francois Lafont]

Bonsoir,

Merci beaucoup Damien pour toutes tes réponses très complète.

Le 31/05/2013 18:33, Damien Wyart a écrit :

> Je vais donner d'autres détails, mais je pense que le plus simple est de
> renoncer à NTP dans les VMs (mais le conserver sur la machine physique
> pour que l'horloge système soit fiable) et d'utiliser les "Vbox Guest
> Additions" pour effectuer le synchronisation des VMs sur la machine
> physique.

Ok. Je vais retenir cette idée simple : "installer ntp sur l'hôte physique et Vbox Guest Additions sur les VMs afin qu'elles se synchronisent toutes seules sur l'horloge système de l'hôte qui, elle, sera fiable".

> Ce qui pose problème n'est pas "l'alignement" de la VM et de la source
> NTP mais le fait que la source de temps de la VM n'est pas assez
> régulière.

Ok, je comprends.

> Sans te vexer

Pas de problème, au contraire. Plus j'apprends de choses sur les forums, plus je suis content que soit en informatique ou dans un autre domaine.

> (je n'aime pas trop reprendre les gens sur ces aspects),
> l'expression correcte est "ne pas être piqué des hannetons" :
> http://www.cnrtl.fr/definition/hanneton, c'est à dire être remarquable
> ou de bonne qualité puisque les hannetons ou autres parasites ne s'y
> attaquent pas.)

Exact, au temps pour moi. ;-)
Merci encore de ton aide.

--
François Lafont