I investigated this approach a bit. This piece of configuration looks
most promising:
weekly
maxsize 2097153
# copytruncate is off
nocreate
maxage 30
sharedscripts
postrotate
kill -HUP virtlogd
endscript
We also need to support reopening log files on SIGHUP in virtlogd of course.
'maxage' allows you to remove outdated rotated files. 'nocreate' is also required
as otherwise logrotate will create foo.log again with a fresh timestamp and
eventually foo.log will never be deleted. We need 'maxsize' instead of 'size'
also. The thing is 'maxage' is only applied on rotation which will never happened
with 'size' if log is abandoned.
Unfortunately 'maxsize' allows weekly rotations which will clash with virtlogd
rotations. I also think of introducing 'forceage' option instead of weekly/maxsize
pair to ask logrotate to apply 'maxage' even without rotation. Still I think
in this way we can clash with virtlogd on managing log files.
I guess we can either make delete/rename in virtlogd/logrotate in a very specific
order to handle races or introduce file locks to cooperate nicely. But to me
it does not look the right way. It will complicate logrotate because it will
need to cooperate with another log files manager.
I would add a new timer/service to cleanup log files. The service can be a very
simple shell script. It will need to cooperate with virtlogd too and we
can use file locks on log files for this purpose.
Yes this will make the log directory much cleaner. Even if we cleanup log
from guestfs in the log directory without this part.