Systemd: RFE: trans-reboot monotonic timers

Created on 24 Apr 2016  ·  3Comments  ·  Source: systemd/systemd

Currently, using monotonic timer units, it does not seem possible to have them persist across reboots.
This would be useful, as it would allow replacement of fcron.

For example, I want a service to run with hourly uptime intervals in between. For example, I would use OnUnitInactiveSec=1h in a timer unit to persistently restart a service with hourly wait times between runs. To get the timer going, I would manually start the service once, but other first-run strategies can be thought of as well.

RFE 🎁 pid1

Most helpful comment

Well, the monotonic clock starts at boottime. And we generally don't know when it stops, since at the time the power is turned off we cannot write to disk anymore where it stopped...

Well, I would say that as anything persistent needs something to be written (to disk), the downtime for monotonic timers starts the moment nothing can be written to disk anymore for the purpose of this persistence. I guess that this transition isn't instantaneous either for suspend to ram/disk. (How long can you write to memory before the system is ‘really’ suspended?) So, I would suggest, as late as reasonably possible in the shutdown process, so right before unmounting the device you're saving the state to.

I would guess that systemd can be at least as accurate as fcron, no?

Why isn't OnCalendar=hourly good enough for cases like this?

I arrived here because I wanted to migrate my personal fcron setup for backups. It probably functions similarly enough using OnCalendar=hourly for hourly intervals, but less so as the intervals become longer.

Consider a service you wish to run after every week of uptime (file system check or so) on a system with very variable multiple shutdow/reboots. It may days between restarts or multiple times a day; it may be uptimes of a few days or a few hours (sounds a bit like my desktop). OnCalendar=weekly will not be a good approximation of a trans-reboot monotonic timer in this case. And if there is no clear trend over larger time periods, using a multiple number of weeks will not help much.

Going back to my own use case, I now actually have OnCalendar=daily, OnCalendar=weekly, and OnCalendar=montly versions that replace the _real uptime_-based daily, weekly, and monthly fcron jobs. I personally find that suboptimal.

All 3 comments

Well, the monotonic clock starts at boottime. And we generally don't know when it stops, since at the time the power is turned off we cannot write to disk anymore where it stopped...

Why isn't OnCalendar=hourly good enough for cases like this?

Well, the monotonic clock starts at boottime. And we generally don't know when it stops, since at the time the power is turned off we cannot write to disk anymore where it stopped...

Well, I would say that as anything persistent needs something to be written (to disk), the downtime for monotonic timers starts the moment nothing can be written to disk anymore for the purpose of this persistence. I guess that this transition isn't instantaneous either for suspend to ram/disk. (How long can you write to memory before the system is ‘really’ suspended?) So, I would suggest, as late as reasonably possible in the shutdown process, so right before unmounting the device you're saving the state to.

I would guess that systemd can be at least as accurate as fcron, no?

Why isn't OnCalendar=hourly good enough for cases like this?

I arrived here because I wanted to migrate my personal fcron setup for backups. It probably functions similarly enough using OnCalendar=hourly for hourly intervals, but less so as the intervals become longer.

Consider a service you wish to run after every week of uptime (file system check or so) on a system with very variable multiple shutdow/reboots. It may days between restarts or multiple times a day; it may be uptimes of a few days or a few hours (sounds a bit like my desktop). OnCalendar=weekly will not be a good approximation of a trans-reboot monotonic timer in this case. And if there is no clear trend over larger time periods, using a multiple number of weeks will not help much.

Going back to my own use case, I now actually have OnCalendar=daily, OnCalendar=weekly, and OnCalendar=montly versions that replace the _real uptime_-based daily, weekly, and monthly fcron jobs. I personally find that suboptimal.

A bit late, but since the issue is still open, I figured I'd offer the following:

OnBootSec=300
OnUnitInactiveSec=3600
RandomizedDelaySec=60

Five minutes after every boot, the attached service would start. Then, an hour after it ends, it restarts. Both times are randomized by up to a minute after their scheduled time.

Derived from the suggestion on the systemd.timer documentation page.

Was this page helpful?
0 / 5 - 0 ratings