Use initstepslew conforme mostrado na documentação .
Por exemplo:
initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
E substitua as baterias ...
Não posso garantir um relógio em tempo real em algumas máquinas (o tempo pode estar errado em horas, meses ou até anos). Como eu também tenho redes intermitentes, configurei o Chrony na esperança de que isso pudesse resolver o problema.
Mas parece que Chrony quer ajustar o relógio lentamente ao longo do tempo, mantendo o relógio monótono e sem mudanças drásticas. Isso é adequado quando o desvio está na ordem de segundos, mas simplesmente não é uma solução para o meu caso (em meus testes, levou horas para corrigir um desvio de 10 minutos). Desativei maxupdateskew , a propósito.
O que eu realmente quero é fazer uma grande mudança cedo na inicialização (não monotônica se o tempo for definido no futuro), com precisão na ordem dos segundos ou (ainda melhor) milissegundos, e depois de aplicado o cliente ntp livre para fazer seus ajustes graduais. Eu supus que esse era um caso de uso importante para clientes ntp, especialmente para máquinas sem um RTC, mas não consigo encontrar soluções bem suportadas para esse problema.
Eu considerei o seguinte:
Executando hwclock --set --date="$(magically-get-correct-time)"; hwclock -s antes que o Chrony faça seu trabalho. O problema é que magically-get-correct-time ainda tem que se reunir sobre o ntp ou outro serviço, e então eu tenho que programar o Chrony para executar depois de ter sucesso .. isso é complicado de fazer (como: e se este comando falhar porque a rede é ruim? rapidamente se torna complicado). Geralmente, isso parece uma fita adesiva.
Usando ntpdate antes de Chrony. O Google diz que isso foi sugerido em alguns fóruns. Eu não sei o quão bem isso funcionaria, e também parece fita adesiva. (também, o ntpdate é relatado como obsoleto)
Neste momento, o que estou procurando é uma maneira de resolver isso usando apenas o Chrony. O que me fez pensar que poderia ser capaz de resolvê-lo era a página no Wiki do Fedora sobre Chrony como padrão NTP cliente . Afirma:
after the initial synchronization the clock is never stepped, this is good for applications which need system time to be monotonic
Para mim, isso sugere que durante algo chamado sincronização inicial , o Chrony pode fazer um passo não-monotônico. Ou então eu espero. Mas na minha instalação, quando diz
Feb 19 17:15:30 black chronyd[696]: System clock wrong by -759.702379 seconds, adjustment started
não pula para corrigi-lo agressivamente o mais rápido possível; Em vez disso, espalha a mudança ao longo de horas, nunca fazendo alterações não monótonas. Então, não vejo nada dessa "sincronização inicial" mencionada. E não consegui descobrir como configurá-lo para fazer qualquer ajuste não-monotônico.
A propósito, eu estou rodando o Arch Linux com o Chrony 1.27
Use initstepslew conforme mostrado na documentação .
Por exemplo:
initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
E substitua as baterias ...