Il semble que depuis la dernière mise à jour de sécurité (Mac OS X
10.4.11 PowerPC), NTP ne fonctionne plus, bien que le démon ntpd
continue de tourner:
(je ne l'ai jamais modifié). Lorsque j'ai remarqué le problème et
rebooté ma machine il y a 14 heures, l'heure était correcte juste
après le reboot. Maintenant j'ai un décalage de 2.65 secondes (et
ça augmente au fur et à mesure...):
$ ntpdate -q time.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time.euro.apple.com
server 17.72.255.12, stratum 2, offset -2.654881, delay 0.10733
server 17.72.255.11, stratum 2, offset -2.654514, delay 0.10555
15 Feb 11:50:37 ntpdate[21997]: step time server 17.72.255.11 offset -2.654514 sec
remote refid st t when poll reach delay offset jitter ============================================================================= time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs, il y a un décalage d'environ 0.2 seconde par heure. Donc:
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout de 25 heures (avant après le reboot de la mise à jour et avant le second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour cela que je m'en étais aperçu). La synchronisation ne fonctionnait donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
_ Sans le "-c /private/etc/ntp-restrict.conf", la synchronisation fonctionne, mais avoir 2 secondes de décalage, c'est tout de même embêtant. Ce qui ne fonctionne pas (et cause ainsi ce problème), c'est le drift. Une idée du pourquoi?
En attendant, la solution est peut-être de diminuer les valeur du minpoll et du maxpoll.
remote refid st t when poll reach delay offset jitter
============================================================================= time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne
de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs,
il y a un décalage d'environ 0.2 seconde par heure. Donc:
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes
après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout
de 25 heures (avant après le reboot de la mise à jour et avant le
second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour
cela que je m'en étais aperçu). La synchronisation ne fonctionnait
donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
_ Sans le "-c /private/etc/ntp-restrict.conf", la synchronisation
fonctionne, mais avoir 2 secondes de décalage, c'est tout de même
embêtant. Ce qui ne fonctionne pas (et cause ainsi ce problème),
c'est le drift. Une idée du pourquoi?
En attendant, la solution est peut-être de diminuer les valeur du
minpoll et du maxpoll.
remote refid st t when poll reach delay offset jitter ============================================================================= time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs, il y a un décalage d'environ 0.2 seconde par heure. Donc:
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout de 25 heures (avant après le reboot de la mise à jour et avant le second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour cela que je m'en étais aperçu). La synchronisation ne fonctionnait donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
_ Sans le "-c /private/etc/ntp-restrict.conf", la synchronisation fonctionne, mais avoir 2 secondes de décalage, c'est tout de même embêtant. Ce qui ne fonctionne pas (et cause ainsi ce problème), c'est le drift. Une idée du pourquoi?
En attendant, la solution est peut-être de diminuer les valeur du minpoll et du maxpoll.
À (at) Sun, 15 Feb 2009 12:32:36 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
> Note: j'ai enlevé l'option -c ... et relancé le démon ntpd avec > > sudo SystemStarter -d restart "Network Time" > > mais je viens de voir (après plus d'une heure) que cela n'a pas résolu > le problème.
C'est donc qu'il n'y a effectivement pas de synchronisation.
En fait si (sans l'option -c), mais il faut attendre les 9 heures du polling. Seul le drift ne fonctionne pas.
C'est donc (encore une fois) une preuve qu'il n'y a effectivement pas de synchronisation (au détail près que la synchronisation peut prendre jusqu'à quelques heures avant d'être établie après un redémarrage du service).
Note: c'est pareil même après les 9 heures du polling. Mais je suppose maintenant que ntptrace ne va pas lire le ntp.conf et qu'il faut lui donner le serveur explicitement. Voici ce que j'obtiens:
$ ntptrace time.euro.apple.com time.euro.apple.com: stratum 2, offset 0.000165, root distance 0.004235 ***Association ID 46746 unknown to server $ ntpdate -q time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time.euro.apple.com server 17.72.255.11, stratum 2, offset -0.746440, delay 0.10551 server 17.72.255.12, stratum 2, offset -0.747216, delay 0.10663 16 Feb 00:14:45 ntpdate[25655]: step time server 17.72.255.11 offset -0.746440 sec
Dans l'article <wt9y6w7ls76.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
À (at) Sun, 15 Feb 2009 12:32:36 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
> Note: j'ai enlevé l'option -c ... et relancé le démon ntpd avec
>
> sudo SystemStarter -d restart "Network Time"
>
> mais je viens de voir (après plus d'une heure) que cela n'a pas résolu
> le problème.
C'est donc qu'il n'y a effectivement pas de synchronisation.
En fait si (sans l'option -c), mais il faut attendre les 9 heures
du polling. Seul le drift ne fonctionne pas.
C'est donc (encore une fois) une preuve qu'il n'y a effectivement pas
de synchronisation (au détail près que la synchronisation peut prendre
jusqu'à quelques heures avant d'être établie après un redémarrage du
service).
Note: c'est pareil même après les 9 heures du polling. Mais je suppose
maintenant que ntptrace ne va pas lire le ntp.conf et qu'il faut lui
donner le serveur explicitement. Voici ce que j'obtiens:
$ ntptrace time.euro.apple.com
time.euro.apple.com: stratum 2, offset 0.000165, root distance 0.004235
***Association ID 46746 unknown to server
$ ntpdate -q time.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time.euro.apple.com
server 17.72.255.11, stratum 2, offset -0.746440, delay 0.10551
server 17.72.255.12, stratum 2, offset -0.747216, delay 0.10663
16 Feb 00:14:45 ntpdate[25655]: step time server 17.72.255.11 offset -0.746440 sec
À (at) Sun, 15 Feb 2009 12:32:36 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
> Note: j'ai enlevé l'option -c ... et relancé le démon ntpd avec > > sudo SystemStarter -d restart "Network Time" > > mais je viens de voir (après plus d'une heure) que cela n'a pas résolu > le problème.
C'est donc qu'il n'y a effectivement pas de synchronisation.
En fait si (sans l'option -c), mais il faut attendre les 9 heures du polling. Seul le drift ne fonctionne pas.
C'est donc (encore une fois) une preuve qu'il n'y a effectivement pas de synchronisation (au détail près que la synchronisation peut prendre jusqu'à quelques heures avant d'être établie après un redémarrage du service).
Note: c'est pareil même après les 9 heures du polling. Mais je suppose maintenant que ntptrace ne va pas lire le ntp.conf et qu'il faut lui donner le serveur explicitement. Voici ce que j'obtiens:
$ ntptrace time.euro.apple.com time.euro.apple.com: stratum 2, offset 0.000165, root distance 0.004235 ***Association ID 46746 unknown to server $ ntpdate -q time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time.euro.apple.com server 17.72.255.11, stratum 2, offset -0.746440, delay 0.10551 server 17.72.255.12, stratum 2, offset -0.747216, delay 0.10663 16 Feb 00:14:45 ntpdate[25655]: step time server 17.72.255.11 offset -0.746440 sec
À (at) Sun, 15 Feb 2009 23:22:43 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Je ne comprends pas bien cette question. Tu veux dire qu'il y a des connexions entrantes sur le port UDP 123? Uniquement avec ntptrace?
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise le protocole UDP sur le port 123 pour échanger des paquets (les version récentes acceptent aussi des échanges via TCP mais je ne sais pas si les clients Apple et si les serveurs que tu as choisis l'acceptent).
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 23:22:43 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
Je ne comprends pas bien cette question. Tu veux dire qu'il y a des
connexions entrantes sur le port UDP 123? Uniquement avec ntptrace?
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise
le protocole UDP sur le port 123 pour échanger des paquets (les
version récentes acceptent aussi des échanges via TCP mais je ne sais
pas si les clients Apple et si les serveurs que tu as choisis
l'acceptent).
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et
éventuellement de le rediriger sur une éventuelle passerelle NAT. Si
ça se fait en TCP, il n'y a pas le problème.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 23:22:43 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Je ne comprends pas bien cette question. Tu veux dire qu'il y a des connexions entrantes sur le port UDP 123? Uniquement avec ntptrace?
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise le protocole UDP sur le port 123 pour échanger des paquets (les version récentes acceptent aussi des échanges via TCP mais je ne sais pas si les clients Apple et si les serveurs que tu as choisis l'acceptent).
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Vincent Lefevre
Dans l'article , Paul Gaborit écrit:
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise le protocole UDP sur le port 123 pour échanger des paquets (les version récentes acceptent aussi des échanges via TCP mais je ne sais pas si les clients Apple et si les serveurs que tu as choisis l'acceptent).
Les pages man ne parlent que d'UDP. Et un "netstat -a" suggère que seul UDP est utilisé.
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
Avec ma machine du réseau local sous Linux, j'ai aussi un ntpdate lancé toutes les heures; mais si je me souviens bien, cette config vient d'un bug d'une vieille version de ntpd (qui introduisait un décalage de plusieurs heures dans l'horloge hardware) et je n'ai jamais changé.
Maintenant, il semble que sur les deux machines de mon réseau local (celle sous Linux et celle sous Mac OS X), le NTP fonctionne puisque "ntpq -p" indique des "when" relativement récents. Peut-être qu'un système du style "UDP hole punching"[*] est utilisé.
Sous Linux, le drift fonctionne (la valeur est non nulle). Ce que je ne comprends pas, c'est qu'il ne fonctionne pas sous Mac OS X. Mais ça semble être un problème connu:
http://support.ntp.org/bin/view/Support/KnownOsIssues indique que le ntp.drift n'est jamais mis à jour sous Mac OS X. Ici, le fichier est mis à jour (son mtime est modifié toutes les heures), mais toujours à la valeur 0.000; ceci dit, je suppose que c'est en fait le même problème. La page indique que la version 4.2.4 de ntp.org a un drift qui fonctionne sous Leopard.
Dans l'article <wt9tz6vw6pm.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise
le protocole UDP sur le port 123 pour échanger des paquets (les
version récentes acceptent aussi des échanges via TCP mais je ne sais
pas si les clients Apple et si les serveurs que tu as choisis
l'acceptent).
Les pages man ne parlent que d'UDP. Et un "netstat -a" suggère que
seul UDP est utilisé.
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et
éventuellement de le rediriger sur une éventuelle passerelle NAT. Si
ça se fait en TCP, il n'y a pas le problème.
Avec ma machine du réseau local sous Linux, j'ai aussi un ntpdate
lancé toutes les heures; mais si je me souviens bien, cette config
vient d'un bug d'une vieille version de ntpd (qui introduisait un
décalage de plusieurs heures dans l'horloge hardware) et je n'ai
jamais changé.
Maintenant, il semble que sur les deux machines de mon réseau local
(celle sous Linux et celle sous Mac OS X), le NTP fonctionne puisque
"ntpq -p" indique des "when" relativement récents. Peut-être qu'un
système du style "UDP hole punching"[*] est utilisé.
Sous Linux, le drift fonctionne (la valeur est non nulle). Ce que
je ne comprends pas, c'est qu'il ne fonctionne pas sous Mac OS X.
Mais ça semble être un problème connu:
http://support.ntp.org/bin/view/Support/KnownOsIssues indique que le
ntp.drift n'est jamais mis à jour sous Mac OS X. Ici, le fichier est
mis à jour (son mtime est modifié toutes les heures), mais toujours
à la valeur 0.000; ceci dit, je suppose que c'est en fait le même
problème. La page indique que la version 4.2.4 de ntp.org a un drift
qui fonctionne sous Leopard.
(Note : UDP n'a pas de notion de connexion) Effectivement, NTP utilise le protocole UDP sur le port 123 pour échanger des paquets (les version récentes acceptent aussi des échanges via TCP mais je ne sais pas si les clients Apple et si les serveurs que tu as choisis l'acceptent).
Les pages man ne parlent que d'UDP. Et un "netstat -a" suggère que seul UDP est utilisé.
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
Avec ma machine du réseau local sous Linux, j'ai aussi un ntpdate lancé toutes les heures; mais si je me souviens bien, cette config vient d'un bug d'une vieille version de ntpd (qui introduisait un décalage de plusieurs heures dans l'horloge hardware) et je n'ai jamais changé.
Maintenant, il semble que sur les deux machines de mon réseau local (celle sous Linux et celle sous Mac OS X), le NTP fonctionne puisque "ntpq -p" indique des "when" relativement récents. Peut-être qu'un système du style "UDP hole punching"[*] est utilisé.
Sous Linux, le drift fonctionne (la valeur est non nulle). Ce que je ne comprends pas, c'est qu'il ne fonctionne pas sous Mac OS X. Mais ça semble être un problème connu:
http://support.ntp.org/bin/view/Support/KnownOsIssues indique que le ntp.drift n'est jamais mis à jour sous Mac OS X. Ici, le fichier est mis à jour (son mtime est modifié toutes les heures), mais toujours à la valeur 0.000; ceci dit, je suppose que c'est en fait le même problème. La page indique que la version 4.2.4 de ntp.org a un drift qui fonctionne sous Leopard.
À (at) Mon, 16 Feb 2009 01:44:53 +0100, Paul Gaborit écrivait (wrote):
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
Les lecteurs attentifs auront corrigé d'eux-mêmes. Mias je préfère le faire explicitement pour les archives : le port UDP utilisé par NTP est le 123 et non le 53 ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Mon, 16 Feb 2009 01:44:53 +0100,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et
éventuellement de le rediriger sur une éventuelle passerelle NAT. Si
ça se fait en TCP, il n'y a pas le problème.
Les lecteurs attentifs auront corrigé d'eux-mêmes. Mias je préfère le
faire explicitement pour les archives : le port UDP utilisé par NTP
est le 123 et non le 53 ! ;-)
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Mon, 16 Feb 2009 01:44:53 +0100, Paul Gaborit écrivait (wrote):
Cela peut donc servir d'ouvrir le port 53 en UDP sur le firewall et éventuellement de le rediriger sur une éventuelle passerelle NAT. Si ça se fait en TCP, il n'y a pas le problème.
Les lecteurs attentifs auront corrigé d'eux-mêmes. Mias je préfère le faire explicitement pour les archives : le port UDP utilisé par NTP est le 123 et non le 53 ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Ollivier Robert
Dans l'article <20090215123216$, Vincent Lefevre <vincent+ disait :
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD...
Dans l'article <20090215123216$3a1f@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> disait :
et c'est bizarre, les options -d et -v (indiquées dans la page man)
ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD...
Dans l'article <20090215123216$, Vincent Lefevre <vincent+ disait :
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD...
Vincent Lefevre
Dans l'article <gnblup$pa0$, Ollivier Robert écrit:
Dans l'article <20090215123216$, Vincent Lefevre <vincent+ disait : >et c'est bizarre, les options -d et -v (indiquées dans la page man) >ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
Il existe des utilitaires qui ne supportent pas la contraction d'options, donc dans le doute...
Dans l'article <gnblup$pa0$1@yquem.eurocontrol.fr>,
Ollivier Robert <roberto@removethis.eu.org> écrit:
Dans l'article <20090215123216$3a1f@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> disait :
>et c'est bizarre, les options -d et -v (indiquées dans la page man)
>ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
Il existe des utilitaires qui ne supportent pas la contraction
d'options, donc dans le doute...
Dans l'article <gnblup$pa0$, Ollivier Robert écrit:
Dans l'article <20090215123216$, Vincent Lefevre <vincent+ disait : >et c'est bizarre, les options -d et -v (indiquées dans la page man) >ne fonctionnent pas:
J'ai toujours utilisé "-bd" dans ce genre de cas.
Il existe des utilitaires qui ne supportent pas la contraction d'options, donc dans le doute...
Dans l'article <20090215224248$, Vincent Lefevre <vincent+ écrit:
> Et que dit ntpq -p ?
remote refid st t when poll reach delay offset jitter ============================================================================= > time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs, il y a un décalage d'environ 0.2 seconde par heure. Donc:
Finalement ce n'est pas toujours 9h:
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================= time3.euro.appl 17.72.133.54 2 u 10h 18h 77 79.831 -1927.0 1693.35 $ ntpdate -q time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time4.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time4.euro.apple.com server 17.72.255.12, stratum 2, offset -3.841253, delay 0.10799 server 17.72.255.12, stratum 0, offset 0.000000, delay 0.00000 16 Feb 16:52:56 ntpdate[1401]: step time server 17.72.255.12 offset -3.841253 sec
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout de 25 heures (avant après le reboot de la mise à jour et avant le second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour cela que je m'en étais aperçu). La synchronisation ne fonctionnait donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
et donc ce n'était peut-être pas dû à l'option -c.
En attendant, la solution est peut-être de diminuer les valeur du minpoll et du maxpoll.
Sauf qu'il est indiqué sur ntp.org que Mac OS X Tiger a tendance à écraser ces options changées par l'utilisateur.
De toute façon, comme le drift ne fonctionne pas, autant lancer un ntpdate toutes les demi-heures...
Dans l'article <20090215224248$08c1@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> écrit:
> Et que dit ntpq -p ?
remote refid st t when poll reach delay offset jitter
============================================================================= > time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne
de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs,
il y a un décalage d'environ 0.2 seconde par heure. Donc:
Finalement ce n'est pas toujours 9h:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
============================================================================= time3.euro.appl 17.72.133.54 2 u 10h 18h 77 79.831 -1927.0 1693.35
$ ntpdate -q time.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time4.euro.apple.com
Looking for host time.euro.apple.com and service ntp
host found : time4.euro.apple.com
server 17.72.255.12, stratum 2, offset -3.841253, delay 0.10799
server 17.72.255.12, stratum 0, offset 0.000000, delay 0.00000
16 Feb 16:52:56 ntpdate[1401]: step time server 17.72.255.12 offset -3.841253 sec
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes
après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout
de 25 heures (avant après le reboot de la mise à jour et avant le
second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour
cela que je m'en étais aperçu). La synchronisation ne fonctionnait
donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
et donc ce n'était peut-être pas dû à l'option -c.
En attendant, la solution est peut-être de diminuer les valeur du
minpoll et du maxpoll.
Sauf qu'il est indiqué sur ntp.org que Mac OS X Tiger a tendance
à écraser ces options changées par l'utilisateur.
De toute façon, comme le drift ne fonctionne pas, autant lancer un
ntpdate toutes les demi-heures...
Dans l'article <20090215224248$, Vincent Lefevre <vincent+ écrit:
> Et que dit ntpq -p ?
remote refid st t when poll reach delay offset jitter ============================================================================= > time.euro.apple 17.72.133.54 2 u 133m 9h 37 84.325 -233.72 612.645
et l'offset est redescendu. Apparemment la synchronisation fonctionne de nouveau, mais il faut attendre les 9h du poll. D'après mes calculs, il y a un décalage d'environ 0.2 seconde par heure. Donc:
Finalement ce n'est pas toujours 9h:
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================= time3.euro.appl 17.72.133.54 2 u 10h 18h 77 79.831 -1927.0 1693.35 $ ntpdate -q time.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time4.euro.apple.com Looking for host time.euro.apple.com and service ntp host found : time4.euro.apple.com server 17.72.255.12, stratum 2, offset -3.841253, delay 0.10799 server 17.72.255.12, stratum 0, offset 0.000000, delay 0.00000 16 Feb 16:52:56 ntpdate[1401]: step time server 17.72.255.12 offset -3.841253 sec
_ Le décalage ne devrait jamais dépasser 2 secondes. Les 2.65 secondes après environ 14 heures (cf OP) n'étaient donc pas normal; et au bout de 25 heures (avant après le reboot de la mise à jour et avant le second reboot), le décalage avait atteint 4 ou 5 secondes (c'est pour cela que je m'en étais aperçu). La synchronisation ne fonctionnait donc pas du tout avec "-c /private/etc/ntp-restrict.conf".
et donc ce n'était peut-être pas dû à l'option -c.
En attendant, la solution est peut-être de diminuer les valeur du minpoll et du maxpoll.
Sauf qu'il est indiqué sur ntp.org que Mac OS X Tiger a tendance à écraser ces options changées par l'utilisateur.
De toute façon, comme le drift ne fonctionne pas, autant lancer un ntpdate toutes les demi-heures...
J'ai toujours constaté que ce serveur ne fonctionnait que quand ça lui chantait ;-)
Il faut dire aussi qu'avec tous les macs qui se connectent dessus par défaut, il doit parfois saturer un peu. Il faut savoir par ailleurs que ce n'est pas une bonne utilisation de ntp, pour lequel on peut (et on doit normalement ) utiliser plusieurs serveurs et laisser le protocole décider quel est le bon serveur à un moment donné.
J'avais ici même donné ma méthode pour ce faire. Ce doit être dans ce fil :
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Vincent Lefevre <vincent+news@vinc17.org> wrote:
server time.euro.apple.com minpoll 12 maxpoll 17
J'ai toujours constaté que ce serveur ne fonctionnait que quand ça lui
chantait ;-)
Il faut dire aussi qu'avec tous les macs qui se connectent dessus par
défaut, il doit parfois saturer un peu. Il faut savoir par ailleurs que
ce n'est pas une bonne utilisation de ntp, pour lequel on peut (et on
doit normalement ) utiliser plusieurs serveurs et laisser le protocole
décider quel est le bon serveur à un moment donné.
J'avais ici même donné ma méthode pour ce faire. Ce doit être dans ce
fil :
J'ai toujours constaté que ce serveur ne fonctionnait que quand ça lui chantait ;-)
Il faut dire aussi qu'avec tous les macs qui se connectent dessus par défaut, il doit parfois saturer un peu. Il faut savoir par ailleurs que ce n'est pas une bonne utilisation de ntp, pour lequel on peut (et on doit normalement ) utiliser plusieurs serveurs et laisser le protocole décider quel est le bon serveur à un moment donné.
J'avais ici même donné ma méthode pour ce faire. Ce doit être dans ce fil :
