Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS BSD Problème synchro ntpd depuis upgrade 5.4 -> 6.4-PRERELEASE

Problème synchro ntpd depuis upgrade 5.4 -> 6.4-PRERELEASE

17 réponses
Avatar
Gérald Niel
'soir

après un upgrade qui c'est bien passé j'ai un soucis avec ntpd.
Je ne peux plus me synchroniser sur celui-ci.
Je n'ai rien modifié au firewall (ipf), rien modifié à ntp.conf.

J'ai loupé un truc ? Je n'ai rien trouvé dans /src/UPDATING et une
recherche sur le net ne me donne rien non plus.

@+
--
Gérald Niel
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
xavier
Gérald Niel wrote:

après un upgrade qui c'est bien passé j'ai un soucis avec ntpd.



Que disent ntpdc -p et ntptracce ?

--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Avatar
Gérald Niel
Le Dimanche 21 septembre 2008 à 17:36 UTC, Xavier écrivait sur
fr.comp.os.bsd :

après un upgrade qui c'est bien passé j'ai un soucis avec ntpd.



Que disent ntpdc -p et ntptracce ?



$ ntpdc -p
remote local st poll reach delay offset disp

====================================================================== Íns.ovh.net 213.251.176.72 4 64 1 0.00037 0.774879 2.81735
=ntp.internet-fr 213.251.176.72 2 64 1 0.00131 0.771713 2.81735
=ntp0.oleane.net 213.251.176.72 2 64 1 0.00134 0.776630 2.81735
=ntp.u-psud.fr 213.251.176.72 2 64 1 0.00145 0.772061 2.81735
=ntp1.oleane.net 213.251.176.72 2 64 1 0.00105 0.779631 2.81735
=arcturus.ciril. 2001:41d0:1:374 16 64 0 0.00000 0.000000 3.99217

$ ntptrace
localhost: stratum 16, offset 0.000000, root distance 0.000000

$ sudo ntpdate -u -b 127.0.0.1
21 Sep 19:55:41 ntpdate[34889]: no server suitable for synchronization
found

Je dois avouer que je sèche...

@+
--
Gérald Niel
Avatar
xavier
Gérald Niel wrote:

Je dois avouer que je sèche...



Ben là, moi aussi ...

Mais je crois que le guru ntpd passe souvent par ici ;-)

--
Xav
The cracked brass bells will ring,
To summon back the fire witch
Avatar
Ollivier Robert
Dans l'article ,
Gérald Niel disait :
$ sudo ntpdate -u -b 127.0.0.1
21 Sep 19:55:41 ntpdate[34889]: no server suitable for synchronization
found



sudo ntpdate -bd <l'un-des-sites-précédement-cités>

ntpdate sur toi même ne va pas fonctionner puisque tu n'es pas synchronisé.

Avec un tcpdump/tshark tournant dans ue fenêtre pour voir si ça sort et/ou
revient.

Je dois avouer que je sèche...



Ca me semble bizarre aussi.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=-
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Avatar
Gérald Niel
Le Lundi 22 septembre 2008 à 13:53 UTC, Ollivier Robert écrivait sur
fr.comp.os.bsd :

sudo ntpdate -bd <l'un-des-sites-précédement-cités>



Ça ça fonctionne.

ntpdate sur toi même ne va pas fonctionner puisque tu n'es pas synchronisé.



En fait hors du réseau où se trouve le serveur, le problème est
identique. Le serveur n'étant pas synchronisé.

Avec un tcpdump/tshark tournant dans ue fenêtre pour voir si ça sort et/ou
revient.



En fait c'est très instable, ça synchronise avec un serveur et perd la
synchro. On voit ici le problème :
<http://www.pool.ntp.org/scores/213.251.176.72>
On voit que ça commence à merder après la mise à jour de FreeBSD
5.4-RELEASE vers 6.4-RERELEASE (6-STABLE).

Je dois avouer que je sèche...



Ca me semble bizarre aussi.



N'est ce pas. À tout hasard :

$ ntpq -c rv kimsufi.gegeweb.org
statusf4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.4p5-a Sat Sep 20 19:16:40 CEST 2008 (1)",
processor="i386", system="FreeBSD/6.4-PRERELEASE", leap, stratum=2,
precision=-20, rootdelay=1.316, rootdispersioni.780, peerW004,
refid2.93.2.20,
reftimeÌ825ce4.28f5dcc1 Mon, Sep 22 2008 20:05:24.160, poll=6,
clockÌ825f08.d4cf2722 Mon, Sep 22 2008 20:14:32.831, state=2,
offsetR.842, frequency'3.784, jitter$8.406, noise.255,
stability=0.272, tai=0

Voici un extrait de ntp.log :

22 Sep 19:57:14 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 19:57:36 ntpd[39218]: synchronized to 145.238.203.14, stratum 1
22 Sep 19:57:50 ntpd[39218]: synchronized to 134.157.254.19, stratum 2
22 Sep 19:58:01 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 20:04:24 ntpd[39218]: time reset +0.844113 s
22 Sep 20:04:37 ntpd[39218]: synchronized to 134.157.254.19, stratum 2
22 Sep 20:05:10 ntpd[39218]: synchronized to 145.238.203.14, stratum 1
22 Sep 20:05:22 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 20:13:36 ntpd[39218]: synchronized to 212.37.192.31, stratum 2
22 Sep 20:13:46 ntpd[39218]: synchronized to 192.93.2.20, stratum 1

Voici le ntp.conf :

$ cat /etc/ntp.conf
server canon.inria.fr iburst prefer
server ntp1.jussieu.fr iburst
server ntp-p1.obspm.fr iburst
server ntps1-0.cs.tu-berlin.de iburst
server ntp.internet-fr.net iburst
server ntp.obspm.fr iburst

driftfile /var/db/ntpd.drift
restrict default nomodify notrap

logfile all
logfile /var/log/ntp.log
---EOF---

@+
--
Gérald Niel
Avatar
Ollivier Robert
Dans l'article ,
Gérald Niel disait :
sudo ntpdate -bd <l'un-des-sites-précédement-cités>



Ça ça fonctionne.



Ah, c'est déjà quelque chose.

En fait c'est très instable, ça synchronise avec un serveur et perd la
synchro. On voit ici le problème :
<http://www.pool.ntp.org/scores/213.251.176.72>
On voit que ça commence à merder après la mise à jour de FreeBSD
5.4-RELEASE vers 6.4-RERELEASE (6-STABLE).



Tu as p-e un problème avec l'horloge de cette machine ?

$ ntpq -c rv kimsufi.gegeweb.org
statusf4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.4p5-a Sat Sep 20 19:16:40 CEST 2008 (1)",
processor="i386", system="FreeBSD/6.4-PRERELEASE", leap, stratum=2,
precision=-20, rootdelay=1.316, rootdispersioni.780, peerW004,
refid2.93.2.20,
reftimeÌ825ce4.28f5dcc1 Mon, Sep 22 2008 20:05:24.160, poll=6,
clockÌ825f08.d4cf2722 Mon, Sep 22 2008 20:14:32.831, state=2,
offsetR.842, frequency'3.784, jitter$8.406, noise.255,
stability=0.272, tai=0

Voici un extrait de ntp.log :

22 Sep 19:57:14 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 19:57:36 ntpd[39218]: synchronized to 145.238.203.14, stratum 1
22 Sep 19:57:50 ntpd[39218]: synchronized to 134.157.254.19, stratum 2
22 Sep 19:58:01 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 20:04:24 ntpd[39218]: time reset +0.844113 s



Ca fait beaucoup 0.8s en une seule fois...

22 Sep 20:04:37 ntpd[39218]: synchronized to 134.157.254.19, stratum 2
22 Sep 20:05:10 ntpd[39218]: synchronized to 145.238.203.14, stratum 1
22 Sep 20:05:22 ntpd[39218]: synchronized to 192.93.2.20, stratum 1
22 Sep 20:13:36 ntpd[39218]: synchronized to 212.37.192.31, stratum 2
22 Sep 20:13:46 ntpd[39218]: synchronized to 192.93.2.20, stratum 1

Voici le ntp.conf :

$ cat /etc/ntp.conf
server canon.inria.fr iburst prefer
server ntp1.jussieu.fr iburst
server ntp-p1.obspm.fr iburst
server ntps1-0.cs.tu-berlin.de iburst
server ntp.internet-fr.net iburst
server ntp.obspm.fr iburst



Et sans le iburst ?

Ma machine n'est pas en 6.4-PRE (je suis en 7) mais elle tourne la même
version de ntpd vu que j'ai fait un merge dans les deux branches.

-----
server 127.127.1.0
fudge 127.127.1.0 stratum 10

server 137.194.32.191
server time.nist.gov

driftfile /var/log/ntp.drift

broadcastclient
multicastclient
-----

Et ça fonctionne :

remote refid st t when poll reach delay offset jitter
============================================================================= 127.127.1.0 .LOCL. 10 l 22 64 377 0.000 0.000 0.002
*137.194.32.191 .DCFa. 1 u 294 1024 377 60.816 1.803 0.168
+192.43.244.18 .ACTS. 1 u 294 1024 377 181.698 6.314 1.647

--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=-
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Avatar
Gérald Niel
Le Mardi 23 septembre 2008 à 13:57 UTC, Ollivier Robert écrivait sur
fr.comp.os.bsd :

Tu as p-e un problème avec l'horloge de cette machine ?



C'est possible... Le reboot suite à la mise à jour aurrait dévoilé le
problème ?
Si oui comment tester?

Ca fait beaucoup 0.8s en une seule fois...



Là, ça fait aussi beaucoup :

23 Sep 20:28:16 ntpd[629]: time reset +0.907197 s
23 Sep 20:28:36 ntpd[629]: synchronized to 145.238.203.10, stratum 2
23 Sep 20:31:45 ntpd[629]: synchronized to 213.251.169.205, stratum 2
23 Sep 20:37:30 ntpd[629]: synchronized to 145.238.203.10, stratum 2
23 Sep 20:44:39 ntpd[629]: time reset +0.736707 s
23 Sep 20:44:51 ntpd[629]: synchronized to 213.251.169.205, stratum 2
23 Sep 20:50:07 ntpd[629]: synchronized to 145.238.203.10, stratum 2
23 Sep 20:56:34 ntpd[629]: synchronized to 213.251.169.205, stratum 2
23 Sep 21:00:57 ntpd[629]: time reset +0.734542 s
23 Sep 21:01:20 ntpd[629]: synchronized to 145.238.203.10, stratum 2

Et sans le iburst ?



On va essayer, je l'ai rajouté en fait...

@+
--
Gérald Niel
Avatar
Ollivier Robert
Dans l'article ,
Gérald Niel disait :
C'est possible... Le reboot suite à la mise à jour aurrait dévoilé le
problème ?



C'est possible, il y a plusieurs manière de gérer l'horloge d'un PC et toutes les machines ne sont pas égales à ce niveau...

cf. /var/run/dmesg.boot :

Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850

Voir aussi « sysctl kern.timecounter »

kern.timecounter.tick: 1
kern.timecounter.choice: TSC(-100) ACPI-safe(850) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-safe
kern.timecounter.nsetclock: 7
kern.timecounter.ngetmicrotime: 775072749
kern.timecounter.ngetnanotime: 5
kern.timecounter.ngetbintime: 0
kern.timecounter.ngetmicrouptime: 392875232
kern.timecounter.ngetnanouptime: 3993028
kern.timecounter.ngetbinuptime: 1760102634
kern.timecounter.nmicrotime: 344043720
kern.timecounter.nnanotime: 4270593
kern.timecounter.nbintime: 351283562
kern.timecounter.nmicrouptime: 2306724
kern.timecounter.nnanouptime: 45174
kern.timecounter.nbinuptime: 1591850784
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 18392
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-safe.mask: 4294967295
kern.timecounter.tc.ACPI-safe.counter: 1741432360
kern.timecounter.tc.ACPI-safe.frequency: 3579545
kern.timecounter.tc.ACPI-safe.quality: 850
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 57656095
kern.timecounter.tc.TSC.frequency: 993328418
kern.timecounter.tc.TSC.quality: -100
kern.timecounter.smp_tsc: 0

et ceci :
http://phk.freebsd.dk/pubs/timecounter.pdf

Là, ça fait aussi beaucoup :



Y a clairement un problème.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=-
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Avatar
F. Senault
Le 25 septembre à 11:38, Ollivier Robert a écrit :

Dans l'article ,
Gérald Niel disait :
C'est possible... Le reboot suite à la mise à jour aurrait dévoilé le
problème ?



C'est possible, il y a plusieurs manière de gérer l'horloge d'un PC
et toutes les machines ne sont pas égales à ce niveau...



Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850



kern.timecounter.hardware: ACPI-safe



Ollivier, tu es un dieu.

J'ai une machine avec une horloge complètement explosée qui tourne
péniblement depuis des années avec un script qui resynchronise l'horloge
toutes les deux heures (temps sur lequel elle prend généralement 25
secondes de dérive).

Avec un petit sysctl kern.timecounter.hardware="i8254" vers midi :

http://www.lacave.net/~fred/divers/cragganmore_ntpe_1d_offset.png
http://www.lacave.net/~fred/divers/cragganmore_ntpe_1d_jitter.png

Merci !

Fred
--
The clouds will part and the sky cracks open
And god himself will reach his fucking arm
Through Just to push you down Just to hold you down
(Nine Inch Nails, The Wretched)
Avatar
Patrick Lamaizière
Ollivier Robert wrote:

C'est possible... Le reboot suite à la mise à jour aurrait dévoilé le
problème ?



C'est possible, il y a plusieurs manière de gérer l'horloge d'un PC et toutes les machines ne sont pas égales à ce niveau...



Sur mon kimsufi (un 08) sous 7-STABLE mais d'avant la mise à jour de
ntp ça a l'air de marcher. Tu as quelle version de kimsufi Gérald ?

kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0)
dummy(-1000000) kern.timecounter.hardware: ACPI-fast

Je vais l'updater en 7.1 d'ici ce week-end, je vous dirais.

Et -euh- ça fait longtemps que xntpd_ ne marche plus dans rc.conf ?
1 2