リアルタイムクロックが間違っており（数時間から数年）、起動時に1回限りの非単調な変更が必要です。 Chronyはこれを解決できますか？
一部のマシンでは、正常なリアルタイムクロックを保証できません（時間が数時間、数か月、さらには数年も間違っている可能性があります）。私も断続的なネットワークを持っているので、問題が解決することを期待してChronyをセットアップしました。
しかし、Chronyは、時計を時間の経過とともにゆっくりと調整し、時計を単調に保ち、大幅な変更を加えたくないようです。これは、ドリフトが数秒のオーダーの場合は適切ですが、私の場合の解決策ではありません（私のテストでは、10分のドリフトを修正するのに数時間かかりました）。ちなみに、maxupdateskewを無効にしました。
私が実際に望んでいるのは、起動の早い段階で大きな変更を加え（将来時間が設定されている場合は単調ではない）、秒単位または（さらに良い）ミリ秒単位の精度で、適用後はntpクライアントが自由に行えるようにすることですその段階的な調整。これはntpクライアント、特にRTCのないマシンの重要なユースケースだと思いましたが、この問題に対して十分にサポートされているソリューションを見つけることができません。
私は次のことを考慮しました：
Chronyがジョブを実行する直前に
hwclock --set --date="$(magically-get-correct-time)"; hwclock -sを実行します。問題はmagically-get-correct-timeそれでもntpまたは他のサービスを介して収集する必要があり、成功した後にChronyを実行するようにスケジュールする必要があります。これは実行が難しいです（たとえば、ネットワークが貧弱なためにこのコマンドが失敗した場合はどうなりますか？これはすぐに複雑になる可能性があります） 。一般的に、これはダクトテープのように感じます。Chronyの直前で
ntpdateを使用します。グーグルはこれがいくつかのフォーラムで提案されたと言います。これがどれだけうまくいくかはわかりませんし、ダクトテープのようにも感じます。 （また、ntpdateは非推奨になると報告されています）
今、私が実際に探しているのは、Chronyだけを使ってこれを解決する方法です。 mightで解決できると思ったのは、Fedora Wikiの Chrony as default NTPクライアント 。それは主張します：
最初の同期後、クロックは決してステップされません。これは、システム時間を単調にする必要があるアプリケーションに適しています。
私にとって、これは、初期同期と呼ばれるものの間に、Chronyが非単調なステッピングを行う可能性があることを示唆しています。またはそう私は願っています。しかし、私のインストールでは、
Feb 19 17:15:30 black chronyd[696]: System clock wrong by -759.702379 seconds, adjustment started
それはジャンプせず、できるだけ早く積極的に修正します。代わりに、変更を数時間にわたって分散し、単調でない変更を行うことはありません。したがって、この「初期同期」については言及されていません。そして、anyの非単調調整を行うように構成する方法を見つけることができませんでした。
ちなみに、私はChrony1.27でArchLinuxを実行しています
documentation に示すように、initstepslewを使用します。
例えば：
initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
そして電池を交換してください...