Systemd timer suddenly stopped triggering

For about a year I have had a systemd timer setup to run a shell script daily, based on this stackexchange. It has worked flawlessly until three days ago when it suddenly stopped working, for no obvious reason.

This script is setup to run as root, and the very first thing it does is opening its own log file in /tmp/backup-$$.log. Rebooting the phone does trigger one execution, complete with log entries and correct output. Yet when midnight rolls around there seems to be no attempt for the new day. No traces of any log file in /tmp nor anything relevant at all visible from using journalctl -xn. Running systemctl list-timers now after midnight says the command should NEXT run in “23h”, and lists “n/a” for LAST and PASSED. Output from systemctl status claims the timer is Active (waiting).

I’m on SailfishOS 3.3.0.16 and have been for way longer than since when this issue arrived. No filesystems are full. I mainly use the device for phone calls, barely use any apps and haven’t made any changes to the device for quite a while.

Could there be something which has changed in my SailfishOS system even though I didn’t recently do an upgrade? Are there any packages or patches, which could cause a regression like this, being rolled out between releases?

Any ideas to understanding what might have happened, or how to resume functionality would be appreciated.

Thanks,

1 Like

IIRC systemd skips timer action if trigger time is missed by large enough margin (1 minute?) due to e.g. device being suspended. Based on problem description it seems that the timer is expected to trigger around midnight - which probably means that the devices is not in active use and thus more likely to be in suspend.

Do you have WakeSystem=true set for you timer? That ought to change the timer behaviour so that system is woken up from suspend at timer trigger time.

Thank you, that’s some interesting insight and knowledge.

I’ll try adding WakeSystem=true if it stops working again, but of course merely posting about the problem made systemd decide to now magically make it work again. Murphy might be lurking, so I’ll not jinx my luck by commenting on it any further at this point.