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

Lorsque je demande l'état du démon NTP avec ntpdc -c sysinfoj'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 statusme 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.)

ntp ntpd un invité
la source

J'ai trouvé que Fedora utilise réellement chrony : Configuration de NTP en utilisant la suite chrony

David Tonhofer

Réponses:

systemd-timesyncd est fondamentalement une petite implémentation NTP client uniquement plus ou moins groupée avec des 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 comme un serveur NTP pour d'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 ntpdcsi vous utilisez ntpd et timedatectlsi vous utilisez timesyncd, je ne connais aucun utilitaire capable de lire les deux.

maxf
la source

Comment est-il possible alors que sur un système la synchronisation de ntpd échoue alors que sur l'autre elle réussit (les deux exécutant systemd-timesyncd en parallèle). Je suis certain que cela ne concerne pas un problème de pare-feu car j'ai vérifié les paramètres correspondants. En ce moment, je me retrouve avec deux résultats et je suis tenté de faire confiance à celui qui a réussi, mais j'ai des doutes car les deux clients implémentent le même protocole NTP mais l'un échoue. En fait, je m'attendrais à ce qu'ils travaillent tous les deux.

a_guest

ntpd et timesyncd utilisent des paramètres différents. Avez-vous défini le même serveur de temps pour les deux?

maxf

pouvez-vous utiliser timesyncd pour synchroniser l'heure avec un GPS comme avec ntp?

bakalolo

Systemd-timesyncd est un client SNTP moins précis que NTP. Les lecteurs ne doivent pas être induits en erreur en pensant que systemd-timesyncd est un client NTP léger.

Philip Couling

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 de sondage, 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 suffit 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.

Metaxis
la source