[libvirt] [PATCH v2] logging: ensure virtlogd rollover takes priority over logrotate

[Daniel P. Berrangé]

On Fri, Jul 12, 2019 at 02:55:25AM +0000, Jim Fehlig wrote:
> On 7/10/19 11:14 AM, Daniel P. Berrangé  wrote:
> > The virtlogd config is set to rollover logs every 2 MB.
> > 
> > Normally a logrotate config file is also installed to handle cases where
> > virtlogd is disabled. This is set to rollover weekly with no size
> > constraint.
> > 
> > As a result logrotate can interfere with virtlogd's, rolling over files
> > that virtlogd has already taken care of.
> > 
> > This changes logrotate configs to rollover based on a max size
> > constraint of 2 MB + 1 byte. When virtlogd is running the log files will
> > never get this large, making logrotate a no-op.
> > 
> > If the user changes the size in virtlogd's config to something larger,
> > they are responsible for also changing the logrotate config suitably.
> > 
> > The LXC driver doesn't use virtlogd, but its logrotate config is altered
> > to match the QEMU driver logrotate, just for the sake of consistency.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > ---
> >   src/logging/virtlogd.conf              |  6 ++++++
> >   src/remote/libvirtd.libxl.logrotate.in |  2 +-
> >   src/remote/libvirtd.lxc.logrotate.in   |  2 +-
> >   src/remote/libvirtd.qemu.logrotate.in  | 10 +++++++++-
> >   4 files changed, 17 insertions(+), 3 deletions(-)
> 
> This patch looks good based on requirement of logrotate not interfering with 
> virtlogd rotation, and for that
> 
> Reviewed-by: Jim Fehlig <jfehlig at suse.com>
> 
> But the problem of unpurged log files that Jan was attempting to solve remains. 
> If I understood your response to to his V2 patch [0], virtlogd needs to gain 
> support for purging log files for old transient VMs after some configurable time?

I don't think it needs to be virtlogd really. I was suggesting a standalone
periodic task.

> In the private bug (sorry) that initiated this discussion I suggested adjusting 
> the logrotate config via cloud deployment tool, pushing rotation policy 
> decisions off to the "admin". What is your opinion on fixing this in upstream 
> libvirt vs configuration at deployment?

A local admin is of course free to change the configuration is any way
they desire.  Just that from upstream POV, having logrotate touch files
that are managed by virtlogd puts you in an unsupportable situation.

Regards,
Daniel

> [0] https://www.redhat.com/archives/libvir-list/2019-July/msg00368.html
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|