ntpd vs. systemd-timesyncd - Como obter sincronização NTP confiável?


31

Ao consultar o status do daemon NTP, ntpdc -c sysinfoobtenho a seguinte saída:

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

Isso indica que a sincronização do NTP falhou. No entanto, a hora do sistema é precisa dentro de 1 segundo de precisão. Quando eu executei meu sistema sem conexão de rede pelo mesmo período que o fiz agora, o tempo do sistema se desviaria ~ 10s.

Esse comportamento sugere que o sistema possui outra maneira de sincronizar a hora. Percebi que também existe systemd-timesyncd.service(com o arquivo de configuração em /etc/systemd/timesyncd.conf) e timedatectl statusme dá a hora correta:

      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

Então, minha pergunta é qual é a diferença entre os dois mecanismos? Um deles está obsoleto? Eles podem ser usados ​​em paralelo? Em quem devo confiar quando desejar consultar o status de sincronização do NTP?

(Observe que eu tenho um sistema diferente (em uma rede diferente) para o qual os dois métodos indicam sucesso e geram o tempo correto.)


2
Eu descobri que o Fedora realmente usa o chrony : Configurando o NTP usando o chrony Suite
David Tonhofer

Respostas:


19

systemd-timesyncd é basicamente uma pequena implementação de NTP somente para cliente, mais ou menos empacotada com versões mais recentes do systemd. É mais leve que um ntpd completo, mas apenas suporta sincronização de tempo - ou seja, não pode atuar como um servidor NTP para outras máquinas. Pretende substituir o ntpd para clientes.

Você não deve usar os dois em paralelo, pois, em teoria, eles podem escolher diferentes servidores de tempo com um pequeno atraso entre eles, fazendo com que o relógio do sistema fique periodicamente "nervoso".

Para obter o status, infelizmente você precisa usar ntpdcse usar o ntpd e timedatectlse usar o timesyncd, não conheço nenhum utilitário que possa ler os dois.


Como é possível, então, que em um sistema a sincronização do ntpd esteja falhando e, por outro, seja bem-sucedido (ambos executando systemd-timesyncd em paralelo). Estou certo de que isso não está relacionado a um problema de firewall, pois verifiquei as configurações correspondentes. No momento, tenho dois resultados e sou tentado a confiar no bem-sucedido, no entanto, tenho dúvidas, pois os dois clientes implementam o mesmo protocolo NTP, mas um está falhando. Na verdade, eu esperaria que os dois funcionassem.
a_guest

11
ntpd e timesyncd usam configurações diferentes. Você definiu o mesmo servidor para ambos?
maxf

você pode usar o timesyncd para sincronizar o tempo com um GPS como o ntp?
bakalolo 12/04

Systemd-timesyncd é um cliente SNTP menos preciso que o NTP. Os leitores não devem ser enganados ao pensar que systemd-timesyncd é um cliente NTP leve.
Philip Couling 24/11

14

systemd-timesyncd não disciplina o relógio: o relógio não é treinado ou compensado e o desvio do relógio interno ao longo do tempo não é reduzido. Ele possui lógica rudimentar para ajustar o intervalo da pesquisa, mas sem disciplinar o host terá um tempo desigual para sempre, à medida que o systemd-timesyncd for pressionado ou pressionado em qualquer intervalo que julgue necessário. Também não pode avaliar a qualidade da fonte de tempo remota. É improvável que você obtenha uma precisão muito superior a 100ms. Isso é suficiente para dispositivos simples do usuário final, como laptops, mas definitivamente pode causar problemas para sistemas distribuídos que desejam maior precisão de tempo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.