[gchamonlive]

Moved from cronie to systemd timers because they are resilient to system startup times. My backup strategy is to create a borg archive entry every day at a fixed time. With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.

Btw this is my repo for the backup automation: https://github.com/gchamon/borg-automated-backups

[mid-kid]

Cronie has a mechanism for this, called "anacron", which is called hourly by cron (on my system, /etc/cron.hourly/0anacron), and performs all the /etc/cron.{daily,weekly,monthly} tasks, no matter if the earliest possible schedule was missed (and with a configurable random delay). You can modify /etc/anacrontab to create custom schedules.

To do this at the user level, you can add something like "@hourly anacron -t /path/to/anacrontab -S /path/to/spooldir" to the user's crontab, though I've never tried this.

Many cron implementations have a similar mechanism.

[gchamonlive]

EDITED

This isn't the same as with systemd timer because timer lets you specify when you want to run your service exactly and will fallback to running when the system comes online. With @hourly I lose this control and multiple machines could potentially trigger backups at the same time, hogging the physical hard drives and the network.

[newsoftheday]

> fallback to running when the system comes online.

That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.

I prefer the deterministic behavior of cron, the script will run when it is specified to run, as you said earlier, as long as the system is running; and as I stated in a separate comment, it will run @reboot if I need it to run then.

> With @hourly I lose this control and multiple machines could potentially trigger backups at the same time

Then don't use @hourly, use staggered times, it's very easy.

[PunchyHamster]

> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.

There are two options to fix it;

Disable persist so no catching up on missing scripts. Set OnBoot=5m so it gets ran 5 minutes after boot, so your script (say backup) is ran on boot first, then every time on schedule

Enable persist but just add sleep in ExecStartPre - very "cron" way but there is just no in-systemd option to enable "catch up" script to be delayed

Sadly no option to "run catch-up timers with delay" at least yet

> Then don't use @hourly, use staggered times, it's very easy.

Not in cron. In systemd it's just RandomizedOffsetSec=30m and it is "stable" - same host with same job will always have same delay so on multiple hosts it is spread nicely. There is also non-stable version

[gchamonlive]

> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.

This isn't what happens. If you leave it offline for days it'll only trigger the service only a single time.

[happysadpanda2]

I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"

[gchamonlive]

Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability

[bisby]

If you have 100 different jobs that were supposed to run over the past week, but didn't because offline, when you restart, they they all flood the system on start.

100 jobs all running at different times throughout the week is a very different load than them all falling back and running at the same time on system boot.

[gchamonlive]

I don't, it's a single backup service.

[layer8]

Cron also has @reboot. Not exactly the same, but has been sufficient for me so far.

[gchamonlive]

https://news.ycombinator.com/item?id=48371021

[WhyNotHugo]

Snooze offers similar resilience to the system being offline: https://github.com/leahneukirchen/snooze

I find it very easy to reason about: a single process maps to a single recurring task.

It can track last execution into a file, yielding durable schedules when the host is offline.

[newsoftheday]

I'm sorry, I tried Googling the word "tolates" but I can't find any definition that makes sense?

> runs the service as soons as the system is available.

cron has the @reboot option which I use for a few scripts and works great.

[gchamonlive]

Typo, I meant tolerates. Fixed it.

Not an option either, because if I reboot two machines and the backup starts in both of them it'll cripple my NAS

[capitainenemo]

How does systemd on the 2 machines avoid that? Are they communicating somehow?

[gchamonlive]

No, just different cron schedules. If I just reboot a machine the job doesn't get triggered, only if I start a machine after the cron schedule should have been triggered. To be fair, if I start two machines in these conditions this will happen too, but such situation is much more manageable than rebooting too machines in a short period of time.

[regularfry]

"tolerates".

[michaelcampbell]

> With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.

Cronie doesn't have a `@reboot` meta-trigger?

[gchamonlive]

https://news.ycombinator.com/item?id=48371021