を実行すると、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約1週間前に動作が停止したことがわかりました。したがって、私のシステムでは、システムタイマーが部分的に破損しているようです。
コンピュータを再起動すると問題がなくなると思いました。しかし、これが既知の問題なのか、解決策があるのか疑問に思います。
タイマーを再起動しても違いはありません（例systemctl restart rsnapshot-daily.timer：）。最終実行日はまだ2092年です。
私はArch Linuxでsystemdバージョン234.11-8を使用しています。
答え1
これはシステムクロックによってトリガされたシステムタイマーの動作で、ある時点で将来の時間（2092年など）に誤って設定されました。
- 情熱的なジャガンナット（2017-05-26）。時間/日付変更後、systemdタイマーはリセットされません。。システムエラー＃6036。 GitHub。
答え2
アップデート（2022-08-08）：バグ修正今マージ。次の解決策はもう必要ありません。
アップデート（2023-01-28）：残念ながらバグが修正されました復元されるバージョン252では、別の回帰が発生しました。したがって、問題はまだ存在し、以下の解決策はまだ関連しています。
~までシステムエラー 修正されました。この回避策を使用してタイマーを再同期しました。
- 破損したタイムスタンプがあるすべてのファイルをタッチします。
/var/lib/systemd/timers - マシンを再起動してください
これでsystemctl list-timers、正常な出力が再び表示されます。
~によるとアーチ文書、タイムスタンプファイルを削除するのも安全でなければなりません。
タイマーが同期されていない場合は、.txtファイルからstamp-*ファイルを削除すると便利です
/var/lib/systemd/timers。これは、各タイマーが最後に実行された時刻を示す長さゼロのファイルです。削除すると、次にタイマーが起動したときに書き換えられます。