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
Dans l'article <20090215105533$, Vincent Lefevre <vincent+ écrit:
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:
Quelques info supplémentaires: je remarque que la mise à jour de sécurité a modifié certains fichiers de config liés à NTP. Tout d'abord, dans /System/Library/StartupItems/NetworkTime/NetworkTime,
ntpd -f /var/run/ntp.drift -p /var/run/ntpd.pid
l'option
-c /private/etc/ntp-restrict.conf
a été ajoutée, et ce fichier contient:
# Access restrictions documented in ntp.conf(5) and # http://support.ntp.org/bin/view/Support/AccessRestrictions # Limit network machines to time queries only
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery
# localhost is unrestricted restrict 127.0.0.1 restrict -6 ::1
includefile /private/etc/ntp.conf
Je ne sais pas quelle est la cause du problème, mais de toute façon, comme ma machine est sur un réseau local et protégée par un firewall, je crois que je vais revenir à la version antérieure...
Dans l'article <20090215105533$3e99@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> écrit:
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:
Quelques info supplémentaires: je remarque que la mise à jour de
sécurité a modifié certains fichiers de config liés à NTP. Tout
d'abord, dans /System/Library/StartupItems/NetworkTime/NetworkTime,
ntpd -f /var/run/ntp.drift -p /var/run/ntpd.pid
l'option
-c /private/etc/ntp-restrict.conf
a été ajoutée, et ce fichier contient:
# Access restrictions documented in ntp.conf(5) and
# http://support.ntp.org/bin/view/Support/AccessRestrictions
# Limit network machines to time queries only
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
# localhost is unrestricted
restrict 127.0.0.1
restrict -6 ::1
includefile /private/etc/ntp.conf
Je ne sais pas quelle est la cause du problème, mais de toute façon,
comme ma machine est sur un réseau local et protégée par un firewall,
je crois que je vais revenir à la version antérieure...
Dans l'article <20090215105533$, Vincent Lefevre <vincent+ écrit:
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:
Quelques info supplémentaires: je remarque que la mise à jour de sécurité a modifié certains fichiers de config liés à NTP. Tout d'abord, dans /System/Library/StartupItems/NetworkTime/NetworkTime,
ntpd -f /var/run/ntp.drift -p /var/run/ntpd.pid
l'option
-c /private/etc/ntp-restrict.conf
a été ajoutée, et ce fichier contient:
# Access restrictions documented in ntp.conf(5) and # http://support.ntp.org/bin/view/Support/AccessRestrictions # Limit network machines to time queries only
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery
# localhost is unrestricted restrict 127.0.0.1 restrict -6 ::1
includefile /private/etc/ntp.conf
Je ne sais pas quelle est la cause du problème, mais de toute façon, comme ma machine est sur un réseau local et protégée par un firewall, je crois que je vais revenir à la version antérieure...
À (at) Sun, 15 Feb 2009 10:56:15 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
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...):
Bizarre. Que contient le fichier ntp.drift ?
$ 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
Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port. La commande pour savoir l'état de nptd, c'est 'ntptrace'.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 10:56:15 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
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...):
Bizarre. Que contient le fichier ntp.drift ?
$ 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
Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui
essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se
lancer puisqu'il utilise tous les deux le même port. La commande pour
savoir l'état de nptd, c'est 'ntptrace'.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 10:56:15 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
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...):
Bizarre. Que contient le fichier ntp.drift ?
$ 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
Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port. La commande pour savoir l'état de nptd, c'est 'ntptrace'.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Sun, 15 Feb 2009 11:07:03 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Je ne sais pas quelle est la cause du problème, mais de toute façon, comme ma machine est sur un réseau local et protégée par un firewall, je crois que je vais revenir à la version antérieure...
En tous cas, ça ne vient pas des limitations d'accès ajoutées par ntp-restrict.conf.
La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine que oui mais ça va mieux en le disant...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 11:07:03 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
Je ne sais pas quelle est la cause du problème, mais de toute façon,
comme ma machine est sur un réseau local et protégée par un firewall,
je crois que je vais revenir à la version antérieure...
En tous cas, ça ne vient pas des limitations d'accès ajoutées par
ntp-restrict.conf.
La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine
que oui mais ça va mieux en le disant...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 11:07:03 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Je ne sais pas quelle est la cause du problème, mais de toute façon, comme ma machine est sur un réseau local et protégée par un firewall, je crois que je vais revenir à la version antérieure...
En tous cas, ça ne vient pas des limitations d'accès ajoutées par ntp-restrict.conf.
La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine que oui mais ça va mieux en le disant...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Vincent Lefevre
Dans l'article <1iv6h51.1cnqenj1s0h2lfN%, Olivier Goldberg écrit:
Vincent Lefevre <vincent+ wrote:
> Il semble que depuis la dernière mise à jour de sécurité, NTP ne > fonctionne plus, bien que le démon ntpd continue de tourner:
Je ne l'ai ps encore faite, donc j'ignore. Mais comment sais-tu que ledit ntp ne fonctionne plus?
Parce que le décalage avec l'heure exacte devient de plus en plus important avec le temps (au bout de plusieurs heures).
J'ai en fait détecté le problème, car il y avait un décalage avec mon serveur Subversion, situé sur une autre machine (sous Linux).
> après le reboot. Maintenant j'ai un décalage de 2.65 secondes (et > ça augmente au fur et à mesure...):
Et comment connais-tu ce décalage?
avec "ntpdate -q <ntp_server>", cf la commande que j'avais donnée. C'est indiqué après "offset".
0.000, même à près mise à jour (après une heure), ce qui n'est pas normal.
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.
> $ 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 > > Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche, sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le serveur distant.
Dans l'article <wt94oyw9cqd.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
Bizarre. Que contient le fichier ntp.drift ?
0.000, même à près mise à jour (après une heure), ce qui n'est pas
normal.
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.
> $ 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
>
> Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui
essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se
lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man)
ne fonctionnent pas:
$ ntptrace -d -v
Unknown option: d
Unknown option: v
localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche,
sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le
serveur distant.
0.000, même à près mise à jour (après une heure), ce qui n'est pas normal.
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.
> $ 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 > > Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche, sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le serveur distant.
0.000, même après sa mise à jour (après une heure), ce qui n'est pas normal.
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.
> $ 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 > > Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche, sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le serveur distant.
Dans l'article <wt94oyw9cqd.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
Bizarre. Que contient le fichier ntp.drift ?
0.000, même après sa mise à jour (après une heure), ce qui n'est pas
normal.
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.
> $ 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
>
> Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui
essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se
lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man)
ne fonctionnent pas:
$ ntptrace -d -v
Unknown option: d
Unknown option: v
localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche,
sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le
serveur distant.
0.000, même après sa mise à jour (après une heure), ce qui n'est pas normal.
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.
> $ 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 > > Quelqu'un d'autre a-t-il le même problème?
Encore plus bizarre. Si ntpd fonctionnait vraiment, ntpdate (qui essaye lui-aussi de mettre la machine à l'heure) devrait refuser de se lancer puisqu'il utilise tous les deux le même port.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
Mais ces options ne fonctionnent pas non plus sous Linux. En revanche, sous Linux, l'offset est différent de 0 et j'obtiens un timeout sur le serveur distant.
> En tous cas, ça ne vient pas des limitations d'accès ajoutées par > ntp-restrict.conf.
Normalement non.
> La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine > que oui mais ça va mieux en le disant...
Oui, deux fois. Et deux fois le même problème.
J'ai une machine qui manifestement ne marche pas bien avec ntpd et je n'ai toujours pas trouvé ... Hélas jamais pu cherché très longtemps...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Dans l'article <wt9vdrc7xs3.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
> En tous cas, ça ne vient pas des limitations d'accès ajoutées par
> ntp-restrict.conf.
Normalement non.
> La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine
> que oui mais ça va mieux en le disant...
Oui, deux fois. Et deux fois le même problème.
J'ai une machine qui manifestement ne marche pas bien avec ntpd et je
n'ai toujours pas trouvé ...
Hélas jamais pu cherché très longtemps...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> En tous cas, ça ne vient pas des limitations d'accès ajoutées par > ntp-restrict.conf.
Normalement non.
> La machine a-t-elle été redémarrée depuis lamise à jour ? J'imagine > que oui mais ça va mieux en le disant...
Oui, deux fois. Et deux fois le même problème.
J'ai une machine qui manifestement ne marche pas bien avec ntpd et je n'ai toujours pas trouvé ... Hélas jamais pu cherché très longtemps...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
xavier
Vincent Lefevre <vincent+ wrote:
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
> La commande pour savoir l'état de nptd, c'est 'ntptrace'.
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).
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
C'est pareil ici sous Linux ou sous Mac OS X 10.5.
Mais ces options ne fonctionnent pas non plus sous Linux.
Le port 123 est-il ouvert en UDP sur la machine (et redirigé si en NAT) ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sun, 15 Feb 2009 12:32:36 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
Dans l'article <wt94oyw9cqd.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
Bizarre. Que contient le fichier ntp.drift ?
0.000, même après sa mise à jour (après une heure), ce qui n'est pas
normal.
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.
Non, ntpdate avec l'option -q n'essaie pas de mettre la machine à l'heure.
Ah oui, pardon : je n'avais pas remarqué l'option '-q' (ce qui
explique d'ailleurs la sortie que tu obtiens).
La commande pour savoir l'état de nptd, c'est 'ntptrace'.
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).
et c'est bizarre, les options -d et -v (indiquées dans la page man)
ne fonctionnent pas:
$ ntptrace -d -v
Unknown option: d
Unknown option: v
localhost: stratum 16, offset 0.000000, root distance 0.000000
C'est pareil ici sous Linux ou sous Mac OS X 10.5.
Mais ces options ne fonctionnent pas non plus sous Linux.
Le port 123 est-il ouvert en UDP sur la machine (et redirigé si en
NAT) ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
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).
et c'est bizarre, les options -d et -v (indiquées dans la page man) ne fonctionnent pas:
$ ntptrace -d -v Unknown option: d Unknown option: v localhost: stratum 16, offset 0.000000, root distance 0.000000
C'est pareil ici sous Linux ou sous Mac OS X 10.5.
Mais ces options ne fonctionnent pas non plus sous Linux.
Le port 123 est-il ouvert en UDP sur la machine (et redirigé si en NAT) ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
