"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 rsnapshot@daily.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 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
/var/lib/systemd/timers - Reboot the machine
Now, 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.