Eu tenho dois voxls em rede que estou tentando sincronizar usando o chrony. Os voxls inicializam com tempos de sistema muito diferentes, como anos de diferença. Eu esperaria que o chrony sincronizasse os horários quando o serviço começar a usar makestep, mas depois de iniciar o chrony, ainda observo uma grande diferença no horário do sistema.
As configurações são as seguintes:
#server 10.0.0.102
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
allow 10.0.0
local stratum 8
manual
logdir /var/log/chrony
#client 10.0.0.101
server 10.0.0.102 iburst maxpoll 5 prefer
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
logdir /var/log/chrony
Quando o chrony é inicializado, eu esperaria que ele fosse usado makesteppara sincronizar o cliente de uma só vez, e vejo um ajuste de tempo no status systemclt
root@voxl1:~# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-02-01 21:34:52 UTC; 83 years 0 months ago
Process: 3086 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 3088 (chronyd)
CGroup: /system.slice/chronyd.service
└─3088 /usr/sbin/chronyd
Feb 01 21:34:52 voxl1 systemd[1]: Starting NTP client/server...
Feb 01 21:34:52 voxl1 chronyd[3088]: chronyd version 2.4 starting (+CMDMON +NTP +REFCLOCK +RTC -PRIVDROP -...EBUG)
Feb 01 21:34:52 voxl1 chronyd[3088]: Frequency -0.681 +/- 0.232 ppm read from /var/lib/chrony/drift
Feb 01 21:34:52 voxl1 systemd[1]: Started NTP client/server.
Feb 01 21:34:56 voxl1 chronyd[3088]: Selected source 10.0.0.102
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
Se eu usar chronyc trackingou chronyc sourcespara observar os deslocamentos de tempo, o relatório indica que os horários são sincronizados em 100 microssegundos.
root@voxl1:~# chronyc tracking
Reference ID : 10.0.0.102 (10.0.0.102)
Stratum : 9
Ref time (UTC) : Sun Feb 07 11:08:34 2106
System time : 0.000066503 seconds slow of NTP time
Last offset : -0.000076736 seconds
RMS offset : 0.000044063 seconds
Frequency : 0.785 ppm slow
Residual freq : -0.216 ppm
Skew : 0.987 ppm
Root delay : 0.004293 seconds
Root dispersion : 0.000069 seconds
Update interval : 129.8 seconds
Leap status : Normal
root@voxl1:~# chronyc sources -v
210 Number of sources = 1
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.0.0.102 8 6 377 46 -77us[ -109us] +/- 1953us
No entanto, se eu imprimir a data, ela não corresponderá ao servidor de horário.
cliente 10.0.0.101
root@voxl1:~# date
Sun Feb 7 11:12:00 UTC 2106
servidor 10.0.0.102
root@voxl2:~# date
Thu Jan 1 04:43:02 UTC 1970
Em seguida, tentei acionar um manual chronyc makestep, mas isso também não pareceu surtir efeito.
Por que minha data não é a mesma? O makestep funcionou como pretendido? Existe um limite para o quão longe chronyc makesteppode pisar o relógio?
Edit: Eu tenho uma hipótese, mas não sei como testá-la. Acho que posso estar vendo um erro de subfluxo. 1º de janeiro de 1970 é a época do Unix. Minha hipótese é que, quando o chrony tenta sincronizar o cliente pela primeira vez na inicialização, ocorre um erro de estouro e vejo a mensagem systemctl
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
Essa etapa incorreta empurra o cliente para 2106 e o chrony agora pensa que está sincronizado com o servidor, e é por isso que outras etapas não têm efeito e o deslocamento parece pequeno.
Alguma ideia de como testar essa hipótese?
Sim, há um limite. O mesmo limite que significa que o NTP será prorrogado no ano de 2036.
O formato de registro de data e hora NTP é baseado em segundos de 32 bits (e frações de segundo de 32 bits) ou 136 anos, também conhecido como era NTP . A diferença entre eles é de mais ou menos 68 anos. Qual é a quantidade segura de tempo delta sem que a implementação faça suposições sobre em que era você está.
Na prática, as implementações serão mais conservadoras e assumirão a era alterada antes dos limites da estrutura de dados. O script de configuração do chrony é padronizado para 50 anos antes de sua data de construção. Em outras palavras, por cerca de três anos, 1970 é considerado uma era NTP diferente. Não é, mas geralmente pode-se supor que os relógios foram acertados em algum momento nas últimas 5 décadas.
chrony calculou deltas que o colocariam antes desta era. Então assumiu que a era rolou, fazendo o mod de matemática 136 anos. Este ano menos 1970 é de 53 anos atrás. 136 menos 53 é 83, que é o seu enorme deslocamento:
Uma maneira diferente de ver isso é uma coisa da era NTP é comparar os carimbos de data/hora do servidor e do cliente. Converta ambos em segundos de época do UNIX (
date +%sde GNU coreutils), subtraia 2 ^ 32 e subtraia o menor, e eles estão separados por apenas 42.O tempo do servidor em 1970 é extraordinário. A partir de 2023, estamos 1,6 bilhão de segundos após 1970-01-01 00:00:00 UTC.
Use um relógio de tempo real. O que quer que o cliente tenha iniciado antes de ser pisado parecia razoável? Não precisa ser preciso, acertar a década seria uma melhoria. Mesmo que o hardware ou software comece com uma data codificada, isso pode ser corrigido, semelhante a um RTC com bateria descarregada.
Adicione fontes de tempo mais confiáveis para seu servidor NTP. Se você tiver internet, adicione
pool 2.pool.ntp.orgao chrony.conf. E, com uma visão clara do céu, as antenas de navegação por satélite podem adicionar relógios precisos sem a necessidade de passar por IP.