You are not logged in.
Pages: 1
Below are my systemd timer which I want to run every 4 days 15 mins after boot. I see that it gets run everyday by observing the systemd list-timer command.
Please help me in correcting my timer script. I had origianlly set it successfully to run using anacrontab where it would run 15 mins after boot after every 4 days.
myupdate.timer
[Unit]
Description=Runs script every 4 days to update
[Timer]
#Runs every 4 days 15 min after boot
OnBootSec=15min
OnUnitActiveSec=4d
Persistent=true
Unit=myupdate.service
[Install]
WantedBy=timers.targetmyupdate.service
[Unit]
Description=Script To update
[Service]
Type=simple
ExecStart=<path to the myupdate shell script>Last edited by ozooha (2019-06-12 20:46:25)
Offline
your timer gets started 15min after boot *and* 4d after that.
there is another problem (quoting the systemd.timer manpage):
These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended, the monotonic clock stops too.
a realtime timer (wallclock timer) would be onCalendar. I am not sure how to do 'every 4th day' with "onCalendar=".
Persistent=
[...] Note that this setting only has an effect on timers configured with OnCalendar=. Defaults to false.
the 15min delay could be set in your script, although this messes with Persistent=true.
mb. "RandomizedDelaySec=" ?
Offline
As it is written presently, your timer will start the associated service 15 minutes after boot and then once more, 4 days after that, and that's all.
The 'Persistent' option "only has an effect on timers configured with "OnCalendar=".
If you reboot the machine before the 4 days delay, the timer is reset and so will trigger the service 15 minutes after the reboot and then will wait 4 days to trigger it again.
So if you reboot the machine everyday the service will be started everyday too.
What you need is an 'OnCalendar' expression for every 4 days, coupled with the 'Persistent' option.
Maybe something like this (not tested):
[Unit]
Description=Runs script every 4 days to update
[Timer]
#Runs every 4 days at a chosen hour (here for example 10:15)
OnCalendar=*-*-*/4 10:15
Persistent=true
[Install]
WantedBy=timers.targetOffline
After thinking more on the right expression, it may be better to give it a fixed starting date like this:
OnCalendar=2017-05-26/4 10:15
to prevent the timer from triggering the service at each boot (again not tested by me, but it seems logical).
* matches any value, but a fixed number should be better, with the preceding triggering date kept on disk by the 'Persistent' option.
The expression should match 26 + 4k, ie first 26 then 30, 03, 07, ...
even after a restarting of the timer.
as opposed, I guess, to 'anything + 4k' which first matches the 'anything' value, so should be reset at any restarting of the timer.
All this needs some testings though.
Offline
So I am testing what you suggested so will let you know how they pan out over next few days.
OZooHA
Offline
So apparantly it worked and it showed this (below) when I used systemctl list-timers
However you can see (last line) it does gives n/a for NEXT and LEFT. Is this ok or has something gone wrong?
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2017-05-31 00:00:00 EDT 3h 24min left Tue 2017-05-30 00:00:00 EDT 20h ago logrotate.timer logrotate.s
Wed 2017-05-31 00:00:00 EDT 3h 24min left Tue 2017-05-30 00:00:00 EDT 20h ago man-db.timer man-db.serv
Wed 2017-05-31 00:00:00 EDT 3h 24min left Tue 2017-05-30 00:00:00 EDT 20h ago shadow.timer shadow.serv
Wed 2017-05-31 08:15:52 EDT 11h left Tue 2017-05-30 08:15:52 EDT 12h ago systemd-tmpfiles-clean.timer systemd-tmp
n/a n/a Tue 2017-05-30 08:15:02 EDT 12h ago myupdate.timer myupdate.Thanks
OZooHA
Offline
You get n/a because 2017-05-26/4 only matches 2017-05-26 and 2017-05-30. berbae's first suggestion (post #3) is better.
I think berbae was trying to address the following potential problem (which might not even be a concern for you). Thanks to Persistent=true, if you miss one or more trigger points (because the system is turned off), the service will be started soon after the next boot. But if this catch-up trigger is very close to the next trigger point, the service might even be started twice in one day. Still, it should never run more than once every four days.
Edit: There are a couple of related feature requests.
Last edited by Raynman (2017-05-31 09:01:42)
Offline
n/a n/a Tue 2017-05-30 08:15:02 EDT 12h ago myupdate.timer myupdate.This shows that systemd when computing '26 + 4k' from the 26/4 expression executes only an algebraical calculus, ie 26, 30, 34, ...
It doesn't consider a date calculation, and as '2017-05-34' is not a valid date, it ignores it.
So this method doesn't work for what you intend to do.
Now I think an easy workaround would be to start your script everyday 15 minutes after boot and to verify the 4 days delay in the script using a file to keep the date of the last running operations you want to execute every 4 days; the script would do nothing if the 4 days delay has not elapsed.
If I find a way with only systemd functionalities I will post again to tell you.
Your timer would become for a machine rebooted each day:
[Unit]
Description=Runs script which will verify the 4 days delay before updating
[Timer]
#Runs 15 min after boot
OnBootSec=15min
[Install]
WantedBy=timers.target@Raynman: I did not intend to address what you explained in your post, but to find a solution about the 4 days delay, which can persist across restarting of the timer or rebooting of the machine. And what I suggested in my previous posts doesn't answer this problem. It was not about the missed triggerings during machine inactivity.
Last edited by berbae (2017-06-01 08:28:43)
Offline
Pages: 1