4

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.

5

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:

3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.