Posso responder a alguns desses pontos, incluindo o título.

[...] que sempre se correlacionam com systemd-timesyncda atualização do relógio do sistema. Com isso quero dizer que a primeira mensagem do syslog após um salto de tempo é uma Time has been changedmensagem do syslog:

grep 'Time has been changed' /var/log/syslog
Oct  2 23:53:33 hostname systemd[1]: Time has been changed

Na verdade, esta mensagem não informa qual programa causou o salto de tempo. É apenas um sintoma do salto no tempo.

Isso acontece quando o kernel informa que systemdo relógio foi alterado.[*] systemdresponde escrevendo esta mensagem no log do sistema e, em seguida, recalculando quando alguma .timerunidade precisará ser acionada.

A mensagem é impressa pelo programa systemd, não pelo systemd-timesyncd.

Mais especificamente, o prefixo da mensagem "systemd[1]:" significa que vem do processo ID 1. PID 1 é o processo "init" especial. O projeto systemd também chama isso de "gerente do sistema", para distingui-lo das instâncias systemdque gerenciam serviços de usuário.

O programa chamado systemdnão altera o relógio após a inicialização do sistema.

Na árvore de origem do systemd atual à qual você se vincula, o único programa que lê o RTC/hardware clock/hwclock é timedated, e somente se você o consultar usando timedatectl.

Pelo que me lembro, versões mais antigas do systemdprograma leem o hwclock uma vez no momento da inicialização, antes de executar qualquer outro programa, e configuram o relógio do sistema de acordo. Na versão mais recente, systemdnão faz isso. Há apenas alguns hackers dizendo ao kernel qual fuso horário é usado para o relógio do hardware. (E evitando acionar algo muito específico chamado "time warp").

Em outras palavras, current systemdparece assumir implicitamente que outra coisa inicializa o relógio do sistema. Na maioria dos casos, este será o kernel.

Procure a opção de compilação do kernel "Definir a hora do sistema do RTC na inicialização e retomada" - CONFIG_RTC_HCTOSYS.

Para um entendimento completo, observe que também há uma opção "Definir o horário RTC com base na sincronização NTP" - CONFIG_RTC_SYSTOHC.

[*] As alterações no relógio do sistema são detectadas usando um recurso específico do Linux. Veja TFD_TIMER_CANCEL_ON_SET.

Muito obrigado ao sourcejedi por esta resposta . Isso realmente me levou a encontrar a resposta certa.

Responda a pergunta

Como o Linux usa um relógio em tempo real para manter o relógio do sistema?

Ele faz isso apenas uma vez, durante a inicialização. Ele não consultará o RTC novamente até a próxima reinicialização. Isso é configurável, mas o fará por padrão na maioria das compilações do kernel.

Eu quero saber se um erro com o relógio de tempo real só se apresentaria no relógio do sistema quando um agente de sincronização de tempo (ntpd ou systemd-timesyncd) for atualizado.

A menos que o sistema seja reinicializado, é improvável que a hora no RTC entre no relógio do sistema. Alguns agentes como ntpdpodem ser configurados para usar um RTC como fonte de tempo, mas isso geralmente não é ativado por padrão. É desaconselhável habilitá-lo a menos que você saiba que o RTC é uma fonte de tempo muito boa.

Existe alguma ligação direta entre o relógio do sistema?

Parece que a hora é copiada de outra forma. O RTC é atualizado periodicamente com a hora do sistema. De acordo com a resposta do sourcejedi, isso é feito pelo kernel se CONFIG_RTC_HCTOSYS estiver definido.

Isso pode ser testado:

• Defina o RTC

  # hwclock --set --date='18:28'
  

• Em seguida, verifique a hora RTC a cada poucos minutos com:

  # hwclock
  

O resultado disso será que a hora do sistema não será alterada e o RTC eventualmente reverterá para a hora do sistema.

A causa do salto do tempo no BBB

Como sourcejedi apontou, as mensagens não estavam sendo acionadas por systemd-timesyncd. Eles estavam sendo acionados por connman. A evidência foi (deveria ser) uma mensagem de log espúria em /var/log/syslog:

Oct  3 00:10:37 hostname connmand[1040]: ntp: adjust (jump): -27302612.028018 sec
...
Nov 21 00:07:05 hostname systemd[1]: Time has been changed

antes da versão 1.37 , connman é codificado para sondar promiscuamente o gateway padrão para o momento. Ele não precisa ser configurado por DHCP para fazer isso e se o cliente NTP do connman estiver habilitado (é por padrão) , ele fará isso independentemente de qualquer outra configuração.

No nosso caso, alguns roteadores domésticos estavam realmente respondendo a essas solicitações NTP, mas os resultados não eram muito confiáveis. Particularmente onde o roteador foi reiniciado, ele continuou a distribuir a hora sem realmente saber a hora correta .

Por exemplo, sabemos que pelo menos uma versão do BT Home Hub 5 , quando reinicializado, será padrão para 21 de novembro de 2018 e fornecerá essa data por NTP. Seu próprio cliente NTP corrigirá o problema, mas há uma janela em que ele é distribuído em 21 de novembro de 2018.

Ou seja, esse problema foi causado por nossos clientes reiniciando seu roteador e connman apenas aceitando desta vez.

Vou expressar minha frustração aqui, parece que a beligerância de alguns deixou esse "recurso" no connman por muito tempo. Foi relatado como um problema já em 2015 . E é um "recurso" muito bem escondido. Não há servidores de tempo configurados e nenhuma mensagem de log para explicar o que o connman está fazendo ou documentação sobre o motivo. Se seus equipamentos de teste não tiverem servidor NTP no gateway padrão, você nunca verá isso nos testes.

Como consertar

Estamos analisando duas opções que parecem funcionar:

1. Remova o connman completamente. Parece que a rede funciona bem sem ele; nós ainda não encontramos a razão para ele estar lá em primeiro lugar.

   apt-get remove connman
   

2. Desabilite o NTP no connman editando /var/lib/connmanpara incluir:

   [global]
   TimeUpdates=manual