☰

“systemctl list-timers”显示遥远的未来的最后执行日期

tag-icon • tag-icon systemd systemd-timer
“systemctl list-timers”显示遥远的未来的最后执行日期

当我运行时systemctl list-timers，最后执行的日期是遥远的未来。例如，这是输出的一部分：

$ systemctl list-timers
NEXT                          LEFT                    LAST                          PASSED                  UNIT                         ACTIVATES
Sat 2017-08-19 02:29:16 CEST  6h left                 Wed 2017-08-16 02:50:57 CEST  2 days ago              systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2092-06-29 22:30:00 CEST  74 years 10 months left Sun 2092-06-29 00:22:17 CEST  74 years 10 months left rsnapshot-daily.timer        [email protected]
Mon 2092-06-30 00:00:00 CEST  74 years 10 months left Sun 2092-06-29 00:22:17 CEST  74 years 10 months left fstrim.timer                 fstrim.service
Mon 2092-06-30 00:00:00 CEST  74 years 10 months left Sun 2092-06-29 00:22:17 CEST  74 years 10 months left logrotate.timer              logrotate.service
Mon 2092-06-30 00:00:00 CEST  74 years 10 months left Sun 2092-06-29 00:22:17 CEST  74 years 10 months left man-db.timer                 man-db.service

当我检查我的备份时（这应该是由作业触发的）rsnapshot-daily.timer，我注意到它在大约一周前停止工作。因此，看起来我的系统上的 systemd 计时器部分损坏了。

我认为如果我重新启动机器，问题就会消失。不过，我很好奇这是否是一个已知问题以及是否有任何解决方法？

重新启动计时器并没有什么区别（例如，systemctl restart rsnapshot-daily.timer）。最后执行日期仍是2092年。

我在 Arch Linux 上使用 systemd 版本 234.11-8。

答案1

这是由系统时钟触发的 systemd 计时器行为，该系统时钟在某一时刻被错误地设置为未来的某个时间，在您的例子中是 2092 年：

答案2

更新（2022-08-08）：已修复错误现在合并。希望不再需要以下解决方法。

更新（2023-01-28）：不幸的是，错误修复了将被恢复在 252 版本中，因为它导致了另一次回归。因此，问题仍然存在，下面的解决方法仍然相关。

直到系统错误 已修复，我使用此解决方法使计时器再次同步：

  • 触摸所有带有损坏时间戳的文件/var/lib/systemd/timers
  • 重新启动机器

现在，systemctl list-timers再次显示正常的输出。

根据Arch 文档，删除时间戳文件也应该是安全的：

如果计时器不同步，删除 .txt 文件中的 stamp-* 文件可能会有所帮助/var/lib/systemd/timers。这些是零长度文件，标记每个计时器最后一次运行的时间。如果删除，它们将在下次启动计时器时重建。

相关内容