我正在运行无头无网络树莓派零来控制某些硬件**，有时时间/日期会被损坏，也许还有其他事情。虽然这不是一个完美的解决方案，但自动重新启动机器将是对现状的改进。通常 cron 是这里非常明显的选择，但我相当确定 cron 对于被损坏的日期来说并不健壮。我所说的“损坏”是指它会随机回到四年半之前。我怀疑我添加的 RTC 芯片有缺陷。
那么我能做些什么来相对稳定地应对间歇性时钟错误呢？理想情况下，计算机每 30 天重新启动一次。拥有一个有缺陷的时钟显然会让这个目标变得更加困难，但精度并不那么重要，只要它不是每周重新启动，或者从不重新启动。
我可以通过添加一个 ! 的 cron 脚本来推出自己的解决方案。每天晚上午夜某个地方写入一个文件，然后当 wc 报告超过 30 个字符时重新启动，或者类似的东西，但似乎必须有一个标准的解决方案。
** 在极端的过度杀伤情况下，这台功能齐全的 UNIX 计算机可能相当于 90 年代中期的 SGI O2，它正在操作一个“智能”猫门，该门根据外面的光线水平来锁定或解锁。
答案1
如何检测大的时钟跳跃？
Linux 至少维护两个内部系统时钟:
- “实时时钟”通常与 NTP 服务器保持同步
- “单调时钟”永远不会倒退，只会向前滴答作响
大约向后跳跃 4 年非常可能是由重置实时时钟的原因引起的。单调时钟永远不应该向后跳，这就是它的重点。
因此，如果您监视与系统时钟相比的单调时钟，您可以发现系统时钟突然回跳很长一段时间的时间（很少有时钟会回跳超过一个月）。
如果你有Python，你可以轻松地得到秒级的差异：
python3 << EOF
import time
print(time.time() - time.monotonic())
EOF
这给出了一个数字（以秒为单位），其本身毫无意义，但任何大的变化都会推断出系统时钟跳跃。任何或更糟的变化都-2592000表明跳跃超过 30 天。
像这样的命令sleep应该不受这样的时钟跳跃的影响，因此您应该能够定期运行它。
诊断真正的问题
我陷入了一个非常深的兔子洞，遇到了几乎相同的听起来问题。
这是我职业生涯中的一个月，我不会再回来了。所以我要强调这个答案。它可以帮助您解决根本原因。
您的系统时钟不太可能自发地破坏自身。
系统时钟由软件而不是硬件维护。 RTC（如果您的设备有 RTC）通常只是在启动时读取，以便在重新启动后恢复。除非您有奇怪的ntpd配置，否则您可以安全地排除 RTC。
通常，唯一能自发改变系统时钟的是 NTP 守护程序或 SNTP 守护程序。我的钱会花在 SNTP 守护进程上，因为 NTP 守护进程会检查多个服务器，因此具有很好的容错能力。
一些家用路由器做一些非常肮脏的事情。它们充当 NTP 或 SNTP 服务器。但是，当路由器重新启动时，没有 RTC，路由器软件仅使用固定的日期/时间（例如：软件补丁构建日期？）。尽管日期/时间明显错误，但他们的 NTP 服务器继续发出错误的日期，并且仅当路由器本身已使用 NTP 或 SNTP 更新时才发出正确的日期。
以我几年前处理过的 BT Home 集线器为例，路由器重新配置了它可以使用的每个设备动态主机配置协议。它甚至宣称自己是“Stratum 1”NTP 服务器，这意味着它声称直接连接到时间源（原子钟）。
尝试重新启动路由器几次，看看这是否会触发您的 IOT 设备时间跳跃。