私はいくつかのハードウェア**を制御するためにヘッドレス、ネットワークレスRaspberry Pi Zeroを実行しています。完璧なソリューションではありませんが、システムを自動的に再起動すると、現在の状態よりも改善される可能性があります。一般に、cronはここでは確実な選択ですが、cronは破損した日付には強力ではないと確信しています。私が言う「損傷」とは、ランダムに4年半前にさかのぼるということです。私が追加したRTCチップに欠陥があるようです。
それでは、断続的なクロックエラーに対して比較的安定している場合はどうすればよいですか？理想的には、コンピュータを30日ごとに再起動する必要があります。時計に欠陥があると、この目標は明らかに難しくなりますが、毎週再起動しないか、まったく再起動しない限り、精度はそれほど重要ではありません。
cronスクリプトに!を追加して独自のソリューションをリリースできます。毎晩深夜にどこかにファイルを書き込んだ後、wcが30文字を超えるか、またはそのような内容を報告すると、再起動しますが、標準的な解決策が必要です。
**極端な過剰シナリオでは、90年代半ばSGI O2と同じである可能性があるこのフル機能のUNIXコンピュータは、外部照明レベルに応じてロックまたはロック解除される「スマート」猫ドアを操作しています。
答え1
大きなクロックジャンプを検出するには？
Linuxは少なくとも維持します。内部システムクロック2個:
- 「リアルタイムクロック」は通常NTPサーバーと同期されます。
- 「モノトーンウォッチ」は決して後ろに行かず、今後のみカチカチする
約4年前に戻る非常にリアルタイムクロックをリセットすると発生する可能性があります。単調な時計は絶対にジャンプしないでください。それがポイントです。
したがって、システム時計と比較して単調な時計を監視すると、システム時計が突然長期間後方に移動することがわかります（1ヶ月以上後方に移動する時計はほとんどありません）。
Pythonを使用している場合は、数秒で違いを簡単に確認できます。
python3 << EOF
import time
print(time.time() - time.monotonic())
EOF
これはそれ自体では意味のない数字（秒）を提供しますが、大きな変化があるとシステムクロックジャンプが発生します。変化があるか悪い場合は、-259200030日以上のジャンプを示します。
このようなコマンドはsleepこのようなクロックジャンプの影響を受けてはいけませんので、定期的に実行できるはずです。
本当の問題を診断する
私は非常に深いウサギの洞窟に陥り、ほぼ同じ問題に遭遇しました。
今月は私のキャリアで二度と戻れない一ヶ月でした。だから私は強調したいと思います。この回答。根本的な原因を解決するのに役立ちます。
システムクロックが自然に破壊される可能性はほとんどありません。
システムクロックはハードウェアではなくソフトウェアで維持されます。 RTC（デバイスにある場合）は通常、起動時に読み取りのみを行うため、再起動後に復元できます。奇妙な設定がない場合は、ntpdRTCを安全に除外できます。
通常、システムクロックを自発的に変更できる唯一のものはNTPデーモンまたはSNTPデーモンです。 NTPデーモンは複数のサーバーをチェックして耐障害性に優れているため、私のお金はSNTPデーモンにあります。
一部の家庭用ルーター本当に汚いことをしてください。 NTP または SNTP サーバーとして機能します。ただし、ルータが再起動するとRTCがなくなり、ルータソフトウェアは固定された日付/時刻のみを使用します（たとえば、ソフトウェアパッチビルド日？）。日付/時刻が間違いなく間違っていても、NTPサーバーは引き続き発行します。間違った日付であり、ルータ自体がNTPまたはSNTPを使用して更新された場合にのみ正しい日付をエクスポートします。
私が数年前に作業したBTホームハブの場合、ルーターが使用できるすべてのデバイスを再構成しました。動的ホスト構成プロトコル。 「Stratum 1」もNTPサーバーであると主張しています。つまり、タイムソース（原子時計）に直接接続されていると主張します。
ルータを数回再起動して、IoTデバイスでタイムジャンプが発生していることを確認してください。