rsbackup causes cronmail with lots of WARNINGs and ERRORs if pruning is stopped due to prune-timeout setting

[pm215]

If the prune-timeout setting is used to restrict the time spent pruning old backups, and rsbackup stops pruning in a particular run as a result, I get a big long cron barfmail like this:

/etc/cron.daily/rsbackup:
WARNING: action list timed out, killing subprocesses
WARNING: action list timed out, cancelling remove/mnementh/root/backup2/2020-10-31
WARNING: action list timed out, cancelling remove/mnementh/root/backup2/2020-11-02
WARNING: action list timed out, cancelling remove/mnementh/root/backup2/2020-11-03
WARNING: action list timed out, cancelling remove/mnementh/root/backup2/2020-11-04
WARNING: action list timed out, cancelling remove/orth/boot/backup2/2020-05-20
WARNING: action list timed out, cancelling remove/orth/boot/backup2/2020-05-21
WARNING: action list timed out, cancelling remove/orth/boot/backup2/2020-05-22
[etc etc etc]
WARNING: action list timed out, cancelling remove/orth/root/backup2/2020-11-03
WARNING: action list timed out, cancelling remove/orth/root/backup2/2020-11-04
ERROR: failed to remove /mnt/backup2/mnementh/root/2020-10-30: rm: Terminated
ERROR: failed to remove /mnt/backup2/mnementh/root/2020-10-31: cancelled
ERROR: failed to remove /mnt/backup2/mnementh/root/2020-11-02: cancelled
ERROR: failed to remove /mnt/backup2/mnementh/root/2020-11-04: cancelled
ERROR: failed to remove /mnt/backup2/mnementh/root/2020-11-03: cancelled
ERROR: failed to remove /mnt/backup2/orth/boot/2020-05-20: cancelled
ERROR: failed to remove /mnt/backup2/orth/boot/2020-05-21: cancelled
[etc etc etc]

Since "stopping pruning because the configuration says not to spend too much time pruning" is a normal expected action, it doesn't seem to me to merit a big long list of WARNINGS/ERRORS in cronmail (the format of which is rather long and not very informative). It might be nice to instead have a summary of the current pruning situation in the standard backup-report email ("%d stale backups still awaiting pruning" or something).

(In this case I have a big lot of pending prunes because I've just switched the backup volume from the default pruning policy, which kept 180 or so backups, to the 'decay' policy, whose tuning parameters mean that most of the old every-day backups are now set to be pruned.)

[ewxrjk]

Agreed, a single warning message (mentioning the reason for the timeout) would be plenty. Also:

warning(WARNING_DEPRECATED, "action list timed out, killing subprocesses");

...is obviously the wrong warning category.

[ewxrjk]

Would you be able to test the https://github.com/ewxrjk/rsbackup/tree/issue89 branch to see if it has better behaviour for you?

[pm215]

Not currently, unfortunately -- the backlog of things needing pruning has now been pruned and because i'm now using the decay prune policy there are many fewer backups on a disk at once, so I no longer have or expect to run into the "so many outstanding prune operations that they timeout" situation.