[RFE] Use systemd timers instead of crontab for periodic tasks

[wereii]

Is your feature request related to a problem? Please describe. Not a problem per se. One point of this RFE is to decide if systemd timers would really be an improvement.

Describe the solution you'd like Instead of managing single crontab file we could take advantage of systemd's timers, which mainly offer atomicity out of the box (so no flock/lock files required). To be exact, each line of crontab would be replaced by a $UNIT.service and a $UNIT.timer files. By default timers start services with a same name as the timer itself, unless specified differently in the timer's configuration.

Pros of timers:

• Disabled/enabled by one command (ex. systemctl disable quads-move-and-rebuild.timer or systemctl enable ...) compared to commenting it out of crontab.
• No need for locks. Systemd (as long as the underlying service/unit is properly configured) would never start it again if it's already running - so a timer would fire at it's time but will never start another "instance" of the underlying task.
• Logs in one place - this is a bit of a side effect as the timers operate on top of systemd services (quads-move-and-rebuild.service) and the service stdout/err are automatically captured in journal(ctl). Instead of manually checking log files (or running the task manually to get outputs) you can issue systemctl status $UNIT or journalctl -f -u $UNIT (-f for --follow to see new messages as they are coming in - the same as running the underlying command yourself for output)
• Ability to run & debug the underlying tasks faster. You can simply systemctl disable $UNIT.timer and systemctl start $UNIT.service instead of: comment out the task in crontab, copy the line, start it yourself.

Cons of timers:

• Two files instead of one line
• Depending on the user, crontab might be simpler thus easier

Describe alternatives you've considered Ability to just "manage single crontab file" can be considered a feature.

[grafuls]

+1 on this. We already make use of services for quads-web and quads-server so I believe it would be trivial to implement this too on rpm.spec.

[sadsfae]

I'm leaning towards this also, I'd like to see it in conjunction with another RFE that relies on it like https://github.com/redhat-performance/quads/issues/368 as systemd provides an API and Python wrapper in form of python3-systemd e.g. https://github.com/systemd/python-systemd