"systemctl list-timers" shows last executed dates that are far in the future
When I run
systemctl list-timers, the last executed dates are far in the future. For example, this is part of the output:
$ 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@example.com 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
When I checked my backup, which should be triggered by the
rsnapshot-daily.timer job, I noticed that it stopped working about one week ago. Thus, it looks like the systemd timers are partly broken on my system.
I assume the problem will go away if I reboot my machine. Still, I am curious if it is a known problem and whether there any workarounds?
Restarting the timers did not make a difference (e.g.,
systemctl restart rsnapshot-daily.timer). The last executed dates are still in 2092.
I’m using systemd version 234.11-8 on Arch Linux.
This is systemd timer behaviour that is triggered by a system clock that was at one point erroneously set to a time in the future, the year 2092 in your case:
- Zeal Jagannatha (2017-05-26). systemd timers do not reset after a time/date change. systemd bug #6036. GitHub.
Update (2022-08-08): A bugfix has been merged now. Hopefully, the following workaround is no longer needed.
Update (2023-01-28): Unfortunately, the bugfix had to be reverted in the 252 release since it caused another regression. Thus, the problem is still open and the workaround below is still relevant.
Until the Systemd bug is fixed, I used this workaround to get the timers in sync again:
- Touch all files with broken timestamps in
- Reboot the machine
systemctl list-timers shows sane output again.
According to the Arch documentation, deleting the timestamp files should also be safe:
If a timer gets out of sync, it may help to delete its stamp-* file in
/var/lib/systemd/timers. These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.