A documentação do chrony adverte
ATENÇÃO: Certos softwares serão seriamente afetados por tais saltos no horário do sistema. (Essa é a razão pela qual o chronyd usa o giro normalmente.) Documentação
Mas a documentação não dá exemplos. Quais são os exemplos de software que serão seriamente afetados? O sistema operacional ou algum processo em segundo plano está em risco?
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?