[RFE] Some hook mechanism in atop.daily

[th-hummel]

Hello,

we're using atop-2.4.0-4 on CentOS 8.2.2004 on HPC cluster stateless nodes. This works great and atop is a very precious tool.
Though, we've encountered 2 points which could be subject to enhancement, at least for our use case, both taking place into the atop.daily script :

Cleaning of old log files

a) we find that find -print0 | xargs -0 rm would be more efficient than find -exec rm {} \;

b) as we don't have much space locally, we'd want to keep only the current atop_$CURDAY log file. This is however impossible as, when overriding LOGGENERATIONS (in /etc/sysconfig/atop on CentOS) and set it to 0, this would run a find -mtime +0 which would keep 2 atop_* log files

Note: -mtime +-1, though awkward, would clean all files but -1 is not considered to be a numerical value in this context

Perfom some action after last sample

Again, as we don't have much space locally, we rsync (via a cron job each minute) atop logfiles to some server. This works fine but creates a critical section when atop is restarted: as a matter of fact, this may cause a race between rsync and atop restart relative to the last minute of sample (we're using LOGINTERVAL=60).
Since atop restart introduces 2 delays : the 5 (max) * 1s to catch the SIGUSR2 and the sleep 3 before cleaning old log files (what is this one for by the way ?) this could cut it but I don't like to synchronise with sleep.

To avoid this we should trigger a last sync after the last sample triggered by SIGUSR2 and before the old log removal. Obviously this would force us to do it inside the atop.daily script which we don't like to modify (upgrades, ...) as any upstream or distro non configuration file.

What do you think about introducing some kind of "hook" mechanism to allow the user to run whatever he wants after the last sample and/or to use it's own cleaning method if he wants to, all of this before atop really starts again with a new logfile ? It seems to me that the former could be useful in other use cases than ours.

Thanks for your help

--
Thomas HUMMEL