web-dev-qa-db-fra.com

ntpd vs systemd-timesyncd - Comment obtenir une synchronisation fiable NTP?

Lorsque je demande le statut 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 système est précise avec une précision d'une seconde. 10s.

Ce comportement suggère que le système a une autre façon de synchroniser l'heure. J'ai réalisé qu'il y avait aussi systemd-timesyncd.service (avec le fichier de configuration à /etc/systemd/timesyncd.conf) et timedatectl status me donne l'heure exacte:

      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? Lequel 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.)

ntpntpdsystemd-timesyncd
33
a_guest

systemd-timesyncd est essentiellement un petit client uniquement NTP plus ou moins fournie avec les versions plus récentes de systemd. Il est plus léger qu'un ntpd complet mais ne prend en charge que la synchronisation temporelle - c'est-à-dire qu'il ne peut pas agir un serveur NTP pour les autres machines. Il est destiné à remplacer ntpd pour les clients.

Vous ne devez pas utiliser les deux en parallèle, car en théorie, ils pourraient choisir différents serveurs de temps qui ont un léger délai entre eux, ce qui rend votre horloge système périodiquement "nerveuse".

Pour obtenir le statut, vous devez malheureusement utiliser ntpdc si vous utilisez ntpd et timedatectlsi vous utilisez timesyncd, je ne connais aucun utilitaire capable de lire les deux.

21
maxf

systemd-timesyncd ne fait aucune discipline d'horloge: l'horloge n'est pas entraînée ou compensée, et la dérive de l'horloge interne dans le temps n'est pas réduite. Il a une logique rudimentaire pour ajuster l'intervalle d'interrogation mais sans discipliner l'hôte se retrouvera avec un temps inégal pour toujours car systemd-timesyncd pousse ou tire à n'importe quel intervalle qu'il pense que la dérive à court terme nécessite. Il ne peut pas non plus évaluer la qualité de la source de temps distante. Il est peu probable que vous obteniez une précision bien supérieure à 100 ms. Cela est suffisant pour les appareils simples comme les ordinateurs portables, mais cela pourrait certainement causer des problèmes aux systèmes distribués qui souhaitent une plus grande précision dans le temps.

17
Metaxis