It is disappointing to see barman being packaged with a cron.d script instead of systemd timers for systems that have first-class support for systemd, e.g. Debian.
Systemd timers provides for a far more robust mechanism for scheduling tasks.
For example, instead of using cron to blindly run a script every minute, you can use systemd timers to run a script one minute AFTER the previous execution has ended. That way you do not end up with overlapping runs (and you do not need to write boilerplate code yourself to try to detect overlapping runs, unlike with cron).
Systemd also provides for unified logging via journalctl, so to find barman logs, all I need to do would be journalctl -u barman.service, instead of haivng to grep through a generic dump.
In addition you can also set dependencies. So that the barman cron would only run if network was up, disk was up etc. etc.
So many benefits. Please join us in the 21st century and leave cron as a relic of the past. ;-)
It is disappointing to see
barman
being packaged with acron.d
script instead ofsystemd
timers for systems that have first-class support forsystemd
, e.g. Debian.Systemd timers provides for a far more robust mechanism for scheduling tasks.
For example, instead of using
cron
to blindly run a script every minute, you can usesystemd
timers to run a script one minute AFTER the previous execution has ended. That way you do not end up with overlapping runs (and you do not need to write boilerplate code yourself to try to detect overlapping runs, unlike withcron
).Systemd also provides for unified logging via
journalctl
, so to find barman logs, all I need to do would bejournalctl -u barman.service
, instead of haivng to grep through a generic dump.In addition you can also set dependencies. So that the barman cron would only run if network was up, disk was up etc. etc.
So many benefits. Please join us in the 21st century and leave cron as a relic of the past. ;-)