Puedo responder a algunos de estos puntos, incluido el título.
[...] que siempre se correlacionan con systemd-timesyncd actualizando el reloj del sistema. Con esto quiero decir que el primer mensaje de syslog después de un salto de tiempo es un Time has been changed mensaje de registro del sistema:
grep 'Time has been changed' /var/log/syslog
Oct 2 23:53:33 hostname systemd[1]: Time has been changed
En realidad, este mensaje no le dice qué programa causó el salto de tiempo. Es solo un síntoma del salto en el tiempo.
Ocurre cuando el núcleo le dice a systemd el reloj ha sido cambiado.[*] systemd responde escribiendo este mensaje en el registro del sistema y luego recalculando cuando cualquier .timer será necesario activar las unidades.
El mensaje es impreso por el programa systemd , no por systemd-timesyncd .
Más específicamente, el prefijo del mensaje "systemd[1]:" significa que proviene del proceso ID 1. PID 1 es el proceso especial "init". El proyecto systemd también lo llama "administrador del sistema", para distinguirlo de las instancias de systemd que gestionan los servicios de los usuarios.
El programa llamado systemd no cambia el reloj una vez que el sistema ha terminado de iniciarse.
En el árbol de fuentes systemd actual al que se vincula, el único programa que incluso lee el RTC/hardware clock/hwclock es timedated , y solo si lo consulta usando timedatectl .
Según recuerdo, las versiones anteriores del systemd El programa lee el hwclock una vez en el momento del arranque, antes de ejecutar cualquier otro programa, y configura el reloj del sistema en consecuencia. En la última versión, systemd no hace esto Solo hay algo de piratería para decirle al núcleo qué zona horaria se utiliza para el reloj de hardware. (Y evitando desencadenar algo muy específico llamado "distorsión del tiempo").
En otras palabras, systemd actual parece asumir implícitamente que algo más inicializa el reloj del sistema. En la mayoría de los casos, será el kernel.
Busque la opción de compilación del kernel "Establecer la hora del sistema desde RTC al iniciar y reanudar" - CONFIG_RTC_HCTOSYS .
Para una comprensión completa, observe que también hay una opción "Establecer la hora RTC según la sincronización NTP" - CONFIG_RTC_SYSTOHC .
[*] Los cambios en el reloj del sistema se detectan mediante una característica específica de Linux. Ver TFD_TIMER_CANCEL_ON_SET .
Muchas gracias a sourcejedi por esta respuesta. Esto realmente me llevó a encontrar la respuesta correcta.
Respuesta a la pregunta
¿Cómo usa Linux un reloj de tiempo real para mantener el reloj del sistema?
Lo hace solo una vez, durante el arranque. No volverá a consultar el RTC hasta el próximo reinicio. Esto es configurable, pero lo hará de manera predeterminada en la mayoría de las versiones del kernel.
Quiero saber si un error con el reloj en tiempo real solo se presentaría en el reloj del sistema cuando se actualice un agente de sincronización de tiempo (ntpd o systemd-timesyncd).
A menos que se reinicie el sistema, es poco probable que la hora en el RTC ingrese en el reloj del sistema. A algunos agentes les gusta ntpd se puede configurar para usar un RTC como fuente de tiempo, pero esto no suele estar habilitado de forma predeterminada. No es recomendable habilitarlo a menos que sepa que el RTC es una muy buena fuente de tiempo.
¿Hay algún vínculo directo entre el reloj del sistema?
Parece que la hora se copia al revés. El RTC se actualiza periódicamente con la hora del sistema. Según la respuesta de sourcejedi, esto lo hace el kernel si se establece CONFIG_RTC_HCTOSYS.
Esto se puede probar:
-
Establecer el RTC
# hwclock --set --date='18:28' -
Luego verifique la hora RTC cada pocos minutos con:
# hwclock
El resultado de esto será que la hora del sistema no cambiará en absoluto y el RTC finalmente volverá a la hora del sistema.
La causa de los saltos de tiempo en la BBB
Como señaló sourcejedi, los mensajes no estaban siendo activados por systemd-timesyncd . Estaban siendo activados por connman . La evidencia era (debería ser) un mensaje de registro falso en /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 de la versión 1.37, connman está codificado para sondear promiscuamente la puerta de enlace predeterminada para el tiempo. No es necesario configurar DHCP para hacer esto y si el cliente NTP de connman está habilitado (es por defecto) entonces lo hará independientemente de cualquier otra configuración.
En nuestro caso, algunos enrutadores domésticos estaban respondiendo a estas solicitudes NTP, pero los resultados fueron muy poco confiables. Particularmente donde se reinició el enrutador, continuó entregando la hora sin saber realmente la hora correcta .
Por ejemplo, sabemos que al menos una versión del BT Home Hub 5, cuando se reinicie, se establecerá de manera predeterminada el 21 de noviembre de 2018 y dará esta fecha a través de NTP. Su propio cliente NTP corregirá el problema, pero hay una ventana donde entrega el 21 de noviembre de 2018.
Es decir, este problema se debió en última instancia a que nuestros clientes reiniciaron su enrutador y Connman simplemente aceptó esta vez.
Expresaré mi frustración aquí, parece que la beligerancia de algunos ha dejado esta "característica" en connman durante demasiado tiempo. Se informó como un problema ya en 2015. Y es una "característica" muy bien escondida. No hay servidores de tiempo configurados ni mensajes de registro para explicar qué está haciendo connman o documentación sobre por qué. Si sus equipos de prueba no tienen un servidor NTP en la puerta de enlace predeterminada, nunca verá esto en las pruebas.
Cómo arreglar
Estamos viendo dos opciones que parecen funcionar:
-
Eliminar connman por completo. Parece que la red funciona bien sin él; aún no hemos encontrado la razón por la que está allí en primer lugar.
apt-get remove connman -
Deshabilite NTP en connman editando
/var/lib/connmanpara incluir:[global] TimeUpdates=manual