Comment Linux utilise-t-il une horloge en temps réel ?

Je peux répondre à certains de ces points, y compris le titre.

[...] qui correspondent toujours à systemd-timesyncd mise à jour de l'horloge système. J'entends par là que le tout premier message syslog après un saut dans le temps est un Time has been changed message syslog :

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

En fait, ce message ne vous dit pas quel programme a causé le saut de temps. C'est juste un symptôme du saut dans le temps.

Cela se produit lorsque le noyau indique systemd l'horloge a été modifiée.[*] systemd répond en écrivant ce message dans le journal système, puis en recalculant si n'importe quel .timer les unités devront être déclenchées.

Le message est imprimé par le programme systemd , pas par systemd-timesyncd .

Plus précisément, le préfixe de message "systemd[1] :" signifie qu'il provient de l'ID de processus 1. PID 1 est le processus spécial "init". Le projet systemd l'appelle également le "gestionnaire de système", pour le distinguer des instances de systemd qui gèrent les services aux utilisateurs.

Le programme appelé systemd ne change pas l'horloge une fois que le système a fini de démarrer.

Dans l'arborescence source systemd actuelle à laquelle vous vous connectez, le seul programme qui lit même le RTC / l'horloge matérielle / hwclock est timedated , et uniquement si vous l'interrogez en utilisant timedatectl .

Si je me souviens bien, les anciennes versions du systemd le programme lit l'horloge hwclock une fois au démarrage, avant d'exécuter tout autre programme, et règle l'horloge système en conséquence. Dans la dernière version, systemd ne fait pas cela. Il n'y a que du piratage pour dire au noyau quel fuseau horaire est utilisé pour l'horloge matérielle. (Et en évitant de déclencher quelque chose de très spécifique appelé "déformation temporelle").

En d'autres termes, le systemd actuel semble supposer implicitement que quelque chose d'autre initialise l'horloge système. Dans la plupart des cas, ce sera le noyau.

Recherchez l'option de construction du noyau "Définir l'heure système à partir de RTC au démarrage et reprendre" - CONFIG_RTC_HCTOSYS .

Pour une compréhension complète, notez qu'il existe également une option "Définir l'heure RTC en fonction de la synchronisation NTP" - CONFIG_RTC_SYSTOHC .

[*] Les changements d'horloge système sont détectés à l'aide d'une fonctionnalité spécifique à Linux. Voir TFD_TIMER_CANCEL_ON_SET .

Merci beaucoup à sourcejedi pour cette réponse. Cela m'a vraiment amené à trouver la bonne réponse.

Répondre à la question

Comment Linux utilise-t-il une horloge en temps réel pour maintenir l'horloge système ?

Il ne le fait qu'une seule fois, au démarrage. Il n'interrogera plus le RTC avant le prochain redémarrage. Ceci est configurable, mais le fera par défaut sur la plupart des versions du noyau.

Je veux savoir si une erreur avec l'horloge en temps réel ne se présenterait que dans l'horloge système lors de la mise à jour d'un agent de synchronisation (ntpd ou systemd-timesyncd).

À moins que le système ne soit redémarré, il est peu probable que l'heure dans le RTC entre dans l'horloge système. Certains agents comme ntpd peut être configuré pour utiliser un RTC comme source de temps, mais cela n'est généralement pas activé par défaut. Il est déconseillé de l'activer sauf si vous savez que le RTC est une très bonne source de temps.

Existe-t-il un lien direct entre l'horloge système ?

Il semble que l'heure soit copiée dans l'autre sens. Le RTC est périodiquement mis à jour avec l'heure du système. Selon la réponse de sourcejedi, cela est fait par le noyau si CONFIG_RTC_HCTOSYS est défini.

Cela peut être testé :

• Définir le RTC

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

• Vérifiez ensuite l'heure RTC toutes les quelques minutes avec :

  # hwclock
  

Le résultat sera que l'heure système ne changera pas du tout et que le RTC reviendra éventuellement à l'heure système.

La cause des sauts de temps sur la BBB

Comme sourcejedi l'a souligné, les messages n'étaient pas déclenchés par systemd-timesyncd . Ils étaient déclenchés par connman . La preuve était (devrait être) un faux message de log 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

avant la version 1.37, connman est codé en dur pour interroger de manière promiscuité la passerelle par défaut pour le moment. Il n'a pas besoin d'être configuré en DHCP pour ce faire et si le client NTP de connman est activé (c'est par défaut) alors il le fera indépendamment de toute autre configuration.

Dans notre cas, certains routeurs domestiques répondaient en fait à ces requêtes NTP, mais les résultats étaient très peu fiables. En particulier lorsque le routeur a été redémarré, il a continué à donner l'heure sans vraiment connaître l'heure exacte .

Par exemple, nous savons qu'au moins une version du BT Home Hub 5, une fois redémarrée, sera par défaut le 21 novembre 2018 et communiquera cette date via NTP. Son propre client NTP corrigera alors le problème, mais il y a une fenêtre où il distribue le 21 novembre 2018.

C'est-à-dire que ce problème a finalement été causé par le fait que nos clients ont redémarré leur routeur et que connman a simplement accepté cette fois.

Je vais exprimer ma frustration ici, il semble que la belligérance de certains ait laissé cette "fonctionnalité" dans Connman depuis bien trop longtemps. Cela a été signalé comme un problème dès 2015. Et c'est une "fonctionnalité" vraiment bien cachée. Il n'y a pas de serveurs de temps configurés et aucun message de journal pour expliquer ce que fait connman ou la documentation expliquant pourquoi. Si vos plates-formes de test n'ont pas de serveur NTP sur la passerelle par défaut, vous ne le verrez jamais lors des tests.

Comment réparer

Nous examinons deux options qui semblent fonctionner :

1. Supprimez complètement connman. Il semble que le réseau fonctionne très bien sans cela ; nous n'avons pas encore trouvé la raison de sa présence.

   apt-get remove connman
   

2. Désactivez NTP dans connman en modifiant /var/lib/connman à inclure :

   [global]
   TimeUpdates=manual