Lorsque je demande l'état du démon NTP avec ntpdc -c sysinfo
j'obtiens la sortie suivante:
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -20
root distance: 0.00000 s
root dispersion: 12.77106 s
reference ID: [73.78.73.84]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
Cela indique que la synchronisation NTP a échoué. Cependant, l'heure du système est précise avec une précision d'une seconde. Lorsque je faisais fonctionner mon système sans connexion réseau pendant la même période que maintenant, l'heure du système s'écartait d'environ 10 secondes.
Ce comportement suggère que le système a une autre façon de synchroniser l'heure. J'ai réalisé qu'il y en avait aussi systemd-timesyncd.service
(avec le fichier de configuration à /etc/systemd/timesyncd.conf
) et timedatectl status
me donne l'heure correcte:
Local time: Thu 2016-08-25 10:55:23 CEST
Universal time: Thu 2016-08-25 08:55:23 UTC
RTC time: Thu 2016-08-25 08:55:22
Time zone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2016-03-27 01:59:59 CET
Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2016-10-30 02:59:59 CEST
Sun 2016-10-30 02:00:00 CET
Ma question est donc quelle est la différence entre les deux mécanismes? L'un d'eux est-il obsolète? Peuvent-ils être utilisés en parallèle? À laquelle dois-je faire confiance lorsque je souhaite interroger l'état de synchronisation NTP?
(Notez que j'ai un système différent (dans un réseau différent) pour lequel les deux méthodes indiquent le succès et donnent l'heure correcte.)