Linux はリアルタイムクロックをどのように使用しますか?

タイトルを含め、これらの点のいくつかについてはお答えできます。

[...] 常に systemd-timesyncd と相関します システムクロックの更新。これは、タイム ジャンプ後の最初の syslog メッセージが Time has been changed であることを意味します。 syslog メッセージ:

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

実際には、このメッセージはタイム ジャンプの原因となったプログラムを示していません。まさにタイムジャンプの症状です。

カーネルが systemd を伝えたときに発生します 時計が変更されました。[*] systemd このメッセージをシステム ログに書き込み、.timer が発生した場合に再計算することで応答します。 ユニットをトリガーする必要があります。

メッセージはプログラム systemd によって出力されます 、 systemd-timesyncd ではありません .

より具体的には、メッセージのプレフィックス「systemd[1]:」は、プロセス ID 1 からのものであることを意味します。PID 1 は特別な「init」プロセスです。 systemd プロジェクトでは、これを「システム マネージャー」とも呼び、systemd のインスタンスと区別しています。 ユーザー サービスを管理します。

systemdというプログラム システムの起動が完了した後、クロックは変更されません。

リンク先の現在のsystemdソースツリーでは、RTC /ハードウェアクロック/ hwclockさえも読み取る唯一のプログラムは timedated です 、および timedatectl を使用してクエリした場合のみ .

systemd の古いバージョンを思い出すと、 プログラムは、他のプログラムを実行する前に、起動時に一度 hwclock を読み取り、それに応じてシステムクロックを設定します。最新バージョンでは、systemd これはしません。カーネルにどのタイムゾーンかを伝えるハッカーがいくつかあるだけです ハードウェアクロックに使用されます。 (そして、「タイム ワープ」と呼ばれる非常に特殊なもののトリガーを回避します)。

つまり、現在の systemd 他の何かがシステムクロックを初期化すると暗黙的に想定しているようです。ほとんどの場合、これはカーネルになります。

カーネル ビルド オプション「起動と再開時に RTC からシステム時間を設定する」を参照してください - CONFIG_RTC_HCTOSYS .

丸みを帯びた理解のために、「NTP 同期に基づいて RTC 時刻を設定する」オプションもあることに注意してください - CONFIG_RTC_SYSTOHC .

[*] システム クロックの変更は、Linux 固有の機能を使用して検出されます。 TFD_TIMER_CANCEL_ON_SET を参照 .

この回答をくれた sourcejedi に感謝します。これにより、正しい答えを見つけることができました。

質問への回答

Linux はどのようにリアルタイム クロックを使用してシステム クロックを維持していますか?

これは、起動時に 1 回だけ行われます。次回の再起動まで、RTC に再度問い合わせることはありません。これは構成可能ですが、ほとんどのカーネル ビルドではデフォルトで構成されます。

timesync エージェント (ntpd または systemd-timesyncd) が更新されたときに、リアルタイム クロックのエラーがシステム クロックにのみ現れるかどうかを知りたいです。

システムを再起動しない限り、RTC の時刻がシステム クロックに反映されることはほとんどありません。 ntpd のような一部のエージェント RTC を時刻源として使用するように構成できますが、これは通常、デフォルトでは有効になっていません。 RTC が非常に優れたタイム ソースであることがわかっている場合を除き、これを有効にすることはお勧めできません。

システムクロック間に直接リンクはありますか?

時間が逆にコピーされているようです。 RTC は、システム時間で定期的に更新されます。 sourcejedi の回答によると、CONFIG_RTC_HCTOSYS が設定されている場合、これはカーネルによって行われます。

これはテストできます:

• RTC を設定する

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

• 次に、数分ごとに RTC 時刻を確認します:

  # hwclock
  

この結果、システム時刻はまったく変更されず、RTC は最終的にシステム時刻に戻ります。

BBB のタイム ジャンプの原因

sourcejedi が指摘したように、メッセージは systemd-timesyncd によってトリガーされていませんでした .それらは connman によってトリガーされていました .証拠は (あるはず) でした /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

バージョン 1.37 より前では、connman は無差別にデフォルト ゲートウェイをポーリングするようにハード コードされています。これを行うために DHCP を構成する必要はありません。また、connman の NTP クライアントが有効になっている場合 (デフォルトです) その後、他の構成に関係なくこれを行います。

私たちのケースでは、一部の家庭用ルーターがこれらの NTP 要求に実際に応答していましたが、結果は非常に信頼できませんでした。特にルーターが再起動された場所では、正確な時刻を実際に知らずに時刻を出し続けていました .

たとえば、BT Home Hub 5 の少なくとも 1 つのバージョンは、再起動時にデフォルトで 2018 年 11 月 21 日に設定され、この日付を NTP 経由で提供することがわかっています。その後、独自の NTP クライアントが問題を修正しますが、2018 年 11 月 21 日に配布するウィンドウがあります。

つまり、この問題は最終的に、お客様がルーターを再起動し、connman がこの時間を受け入れたことが原因でした。

ここでフラストレーションを表明します。好戦的な人たちが、connman にこの「機能」をあまりにも長い間放置してしまったようです。これは 2015 年に問題として報告されました。そして、これは非常によく隠されている「機能」です。構成されたタイムサーバーはなく、connman が何を行っているかを説明するログ メッセージも、理由に関するドキュメントもありません。テスト リグのデフォルト ゲートウェイに NTP サーバーがない場合、テストでこれが表示されることはありません。

修正方法

どちらも機能するように見える 2 つのオプションを検討しています:

apt-get remove connman

[global]
TimeUpdates=manual