Jak Linux používá hodiny reálného času?

Mohu odpovědět na některé z těchto bodů, včetně názvu.

[...] které vždy korelují s systemd-timesyncd aktualizaci systémových hodin. Tím chci říct, že úplně první zpráva syslog po časovém skoku je Time has been changed zpráva syslog:

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

Ve skutečnosti vám tato zpráva neříká, který program způsobil časový skok. Je to jen příznak časového skoku.

Stane se to, když jádro řekne systemd hodiny byly změněny.[*] systemd odpoví zapsáním této zprávy do systémového protokolu a poté přepočítá, když je .timer jednotky bude nutné spustit.

Zprávu vytiskne program systemd , nikoli podle systemd-timesyncd .

Přesněji řečeno, předpona zprávy "systemd[1]:" znamená, že pochází z ID procesu 1. PID 1 je speciální "init" proces. Projekt systemd to také nazývá "správce systému", aby se odlišil od instancí systemd které spravují uživatelské služby.

Program nazvaný systemd nezmění hodiny po dokončení bootování systému.

V aktuálním zdrojovém stromu systemd, na který odkazujete, je jediný program, který dokonce čte RTC / hardwarové hodiny / hwclock, timedated a pouze v případě, že jej zadáte pomocí timedatectl .

Pokud si vzpomínám, starší verze systemd program přečte hwclock jednou při startu před spuštěním jakéhokoli jiného programu a podle toho nastaví systémové hodiny. V nejnovější verzi systemd to nedělá. Existuje jen nějaký hacker, který jádru říká, jaké časové pásmo se používá pro hardwarové hodiny. (A vyvarovat se spuštění něčeho velmi specifického, kterému se říká „časová deformace“).

Jinými slovy, aktuální systemd Zdá se, že implicitně předpokládá, že systémové hodiny inicializuje něco jiného. Ve většině případů to bude jádro.

Vyhledejte možnost sestavení jádra "Nastavit systémový čas z RTC při spuštění a obnovení" - CONFIG_RTC_HCTOSYS .

Pro lepší pochopení je zde také možnost "Nastavit čas RTC na základě synchronizace NTP" - CONFIG_RTC_SYSTOHC .

[*] Změny systémových hodin se zjišťují pomocí funkce specifické pro Linux. Viz TFD_TIMER_CANCEL_ON_SET .

Děkuji moc sourcejedi za tuto odpověď. To mě skutečně přivedlo k nalezení správné odpovědi.

Odpovězte na otázku

Jak Linux používá hodiny reálného času k udržování systémových hodin?

Učiní tak pouze jednou, během bootování. Do příštího restartu nebude znovu dotazovat RTC. Toto je konfigurovatelné, ale bude to dělat ve výchozím nastavení u většiny sestavení jádra.

Chci vědět, zda se chyba s hodinami reálného času projeví pouze v systémových hodinách, když se aktualizuje agent timesync (ntpd nebo systemd-timesyncd).

Pokud není systém restartován, je nepravděpodobné, že se čas v RTC vůbec dostane do systémových hodin. Někteří agenti jako ntpd lze nakonfigurovat tak, aby jako zdroj času používal RTC, ale to není obvykle ve výchozím nastavení povoleno. Nedoporučuje se to povolit, pokud nevíte, že RTC je velmi dobrým zdrojem času.

Existuje nějaké přímé spojení mezi systémovými hodinami?

Zdá se, že čas je zkopírován jiným způsobem. RTC se pravidelně aktualizuje se systémovým časem. Podle odpovědi sourcejedi to provádí jádro, pokud je nastaveno CONFIG_RTC_HCTOSYS.

To lze otestovat:

• Nastavte RTC

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

• Poté každých několik minut zkontrolujte čas RTC pomocí:

  # hwclock
  

Výsledkem toho bude, že se systémový čas vůbec nezmění a RTC se nakonec vrátí k systémovému času.

Příčina času přeskakuje na BBB

Jak upozornil sourcejedi, zprávy nebyly spouštěny systemd-timesyncd . Byly spouštěny connman . Důkaz byl (měl by být) falešná zpráva protokolu v /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

před verzí 1.37 je connman pevně naprogramován k promiskuitnímu dotazování výchozí brány na daný čas. K tomu není nutné konfigurovat DHCP a pokud je connmanův NTP klient povolen (ve výchozím nastavení) pak to udělá bez ohledu na jakoukoli jinou konfiguraci.

V našem případě některé domácí routery skutečně odpovídaly na tyto požadavky NTP, ale výsledky byly vysoce nespolehlivé. Zejména tam, kde byl router restartován, nadále udával čas, aniž by znal správný čas .

Například víme, že alespoň jedna verze BT Home Hub 5 bude po restartu nastavena jako výchozí na 21. listopad 2018 a uvede toto datum přes NTP. Jeho vlastní NTP klient pak problém opraví, ale je tu okno, kde to rozdá 21. listopadu 2018.

To znamená, že tento problém byl nakonec způsoben tím, že naši zákazníci restartovali svůj router a connman právě akceptoval tento čas.

Vyjádřím zde svou frustraci, zdá se, že agresivita některých opustila tuto „funkci“ v connman příliš dlouho. Jako problém to bylo hlášeno už v roce 2015. A je to opravdu dobře skrytá „funkce“. Nejsou nakonfigurovány žádné časové servery a žádná zpráva protokolu, která by vysvětlila, co connman dělá, ani dokumentace proč. Pokud vaše testovací zařízení nemají na výchozí bráně server NTP, při testování to nikdy neuvidíte.

Jak opravit

Díváme se na dvě možnosti, které se zdají fungovat:

1. Odstraňte connman úplně. Zdá se, že síť funguje dobře i bez něj; zatím jsme nenašli důvod, proč tam vůbec je.

   apt-get remove connman
   

2. Zakažte NTP v connman úpravou /var/lib/connman zahrnout:

   [global]
   TimeUpdates=manual