[stryan]

Timers can work with arbitrary units (not just a similarly-named service unit) so they can be surprisingly flexible. I have a timer on my servers that starts a backup.target that fires off a full "restic backup","restic prune", "restic forget" backup cycle each morning with randomized start times and notifications. The actual restic-* units are Podman Quadlets so the whole setup runs agnosticaly of what's on the server, just as long as it has Podman and Systemd installed.

I will admit thought, timers are up there in terms of being the clunkiest systemd unit type to use on a regular basis. I get why they're split up into two files and require different start vs enable syntax's, but man sometimes I just want to create a file that runs a script and be done with it.

[9dev]

I feel like systemd units could need a layer of abstraction above them, so instead of editing the files manually, a tool would do it, some kind of declarative CLI or something. Probably not really a concern in the age of LLMs anymore, but it feels just slightly too tedious every time.

[sureglymop]

I do similar stuff for backups. What's bitten me sometimes was that I disabled the timers in order to do other stuff on the restic repo (e.g. cleaning locks) but didn't see that the triggered units were still running.

[stryan]

Yeah I run my steps as one-shot commands to try to avoid that, but the timer/service split can be very annoying like that.

[esperent]

Why do you randomize your backup times?

[stryan]

Should have been more clear: I use RandomizedOffsetSec= to add a random offset to a set start time (usually 4am), to prevent overloading the backup server, not truly random start times.

[capitainenemo]

As someone else noted, that's also a cron feature

[c-hendricks]

A feature of _some_ cron systems

[capitainenemo]

True. But commonly used ones.