Como provar que a sincronização de tempo NTP está sendo verificada regularmente

Para minha aplicação com tempo limitado, estou preocupado que se semanas/meses passarem sem nenhuma verificação de NTP, o relógio do meu sistema pode variar significativamente.

É possível que essa systemd-timesyncdnão seja a escolha mais apropriada de cliente NTP para você. Você pode querer editar sua pergunta para esclarecer o que significa "sensível ao tempo" para sua aplicação específica:

• Você está mais preocupado em corresponder ao horário padrão oficial ou se preocupa mais em todos os sistemas que executam componentes do aplicativo terem seus relógios correspondentes ?
• Que tipo de precisão você precisa? Ter o carimbo de hora HH:MM:SS correto o suficiente para você, ou você precisa de uma cronometragem precisa de milissegundos ou microssegundos?

A versão mais recente da systemd-timesyncdpágina do manual diz:

O systemd-timesyncdserviço implementa somente SNTP. Este serviço minimalista irá incrementar o relógio do sistema para grandes deslocamentos ou ajustá-lo lentamente para deltas menores. Casos de uso complexos que exigem suporte NTP completo (e onde SNTP não é suficiente) não são cobertos por systemd-timesyncd.

A maioria dos aplicativos sensíveis ao tempo, na minha experiência, exigirá um entendimento detalhado de quando e como grandes transições de passo podem acontecer, ou uma garantia total de que haverá apenas ajustes graduais, nunca transições de passo enquanto o aplicativo estiver em execução. Não li o código-fonte de systemd-timesyncd(ainda), mas não vejo nenhuma maneira de reiniciar systemd-timesyncdcom uma garantia de que não fará nenhuma transição de passo.

Mesmo que systemd-timesyncdtenha verificações de sanidade para evitar retroceder o tempo do sistema enquanto o serviço está em execução, posso ver uma possível interação ruim com atualizações automáticas: se systemd-timesyncdfor reiniciado por uma atualização automática (de si mesmo ou de alguma biblioteca da qual ele depende, como glibc), ele pode fazer uma transição de passo ao reiniciar o systemd-timesyncdserviço, possivelmente até mesmo um passo "para trás no tempo". Para, por exemplo, bancos de dados com dados sensíveis ao tempo, isso seria puro veneno.

Em ambientes modernos, onipresentemente conectados à internet e com crescentes cargas de trabalho de administradores de sistemas e requisitos de conformidade de segurança, não ter atualizações automatizadas está se tornando uma solução impraticável. Portanto, um administrador de sistema deve configurar o sistema para ser tolerante à automação sempre que possível - e com aplicativos sensíveis ao tempo, isso significa, entre outras coisas, prestar atenção para garantir que o serviço de sincronização NTP seja reiniciável/reconfigurável sem causar problemas aos aplicativos de "carga útil" do sistema. Parece-me que isso systemd-timesyncdpode não cumprir esse critério.

/var/lib/systemd/timesync/clockOs registros de data e hora dos /run/systemd/timesync/synchronizedarquivos já mencionados por D'Arcy Nader parecem ser a melhor verificação diária que você pode fazer.

Se você quiser monitoramento em tempo real, também poderá usar o timedatectl timesync-status --monitorcomando nas versões 239 e superiores.

chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- 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
===============================================================================
^* somewhere.com             4  10   377   365   +419us[ +742us] +/-  211ms

observe o ^*significado current best; se você tiver ^?lá, então não está funcionando e não pode ver um servidor de tempo; primeiro tente parar qualquer firewall como service firewalld stope então espere 1 minuto e faça um service chronyd restarte então espere 2 minutos no máximo e verifique novamente chronyc sources. Se você digitar rápido e verificar tudo isso dentro de 5 segundos, você continuará a ver ^?. Primeiro você tem que ter certeza de que está falando com um servidor de tempo com sucesso. Então...

chronyc tracking

Reference ID    : abc123 (somewhere.com)
Stratum         : 5
Ref time (UTC)  : Wed Mar 19 15:15:21 2025
System time     : 0.000113727 seconds fast of NTP time
Last offset     : +0.000323116 seconds
RMS offset      : 0.000678079 seconds
Frequency       : 12.582 ppm fast
Residual freq   : +0.009 ppm
Skew            : 0.151 ppm
Root delay      : 0.021262813 seconds
Root dispersion : 0.201387167 seconds
Update interval : 1035.9 seconds           <---- *** here ***
Leap status     : Normal

se não estiver funcionando, você terá tudo zeros para coisas na saída de rastreamento. Essa saída de rastreamento deve fazer sentido.

em /etc/chrony.confter esses dois sem comentários eservice chronyd restart

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking

e supondo que você queira dizer chonyde não ntpdtão bem... Diferença entre chronyd e ntpd

citando deman systemd-timesyncd.service

   /var/lib/systemd/timesync/clock
       The modification time ("mtime") of this file is updated on
       each successful NTP synchronization or after each
       SaveIntervalSec= time interval, as specified in
       timesyncd.conf(5).

       If present, the modification time of this file is used for the
       epoch by systemd(1) and systemd-timesyncd.service.

       Added in version 219.

   /run/systemd/timesync/synchronized
       A file that is touched on each successful synchronization to
       assist systemd-time-wait-sync and other applications in
       detecting synchronization to an accurate reference clock.

       Added in version 239.