Re: [PATCH] logging: remove concept of default log priority

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 31, 2016 at 10:52:35AM +0200, Erik Skultety wrote:
> On 11/05/16 16:12, Daniel P. Berrange wrote:
> > The logging framework has categories which can be selectively
> > enabled/disabled by setting a suitable LIBVIRT_LOG_FILTERS
> > environment variable or config file setting.
> > 
> > Along side that we also have the LIBVIRT_DEBUG environment
> > variable which unconditionally enables every single category
> > at DEBUG level. With the amount of logging produced by libvirt
> > these days, the signal/noise ratio in the output from setting
> > LIBVIRT_DEBUG is to poor for it to be useful.
> > 
> > Originally the LIBVIRT_DEBUG env variable had a very specific
> > use case - it resulted in logging of anything in our public
> > API entrypoints. eg it turned on src/libvirt.c debugging and
> > nothing else. Additionally it would always result in log
> > messages being sent to stderr.
> > 
> > When applied to any of the daemons, the log output no longers
> > gets sent to stderr, but rather to whatever default log output
> > has been configured by the daemon. If no log_outputs setting
> > or LIBVIRT_LOG_OUTPUTS env is set, then messages will often
> > go to the systemd journal or a /var/log/libvirt/libvirtd.log
> > file rather than stderr.
> > 
> > These factors have conspired to make the LIBVIRT_DEBUG env
> > and/or default log priority to be pretty useless in the real
> > world.
> > 
> > This change attempts to take us back towards the original
> > semantics of the LIBVIRT_DEBUG env variable as follows.
> > 
> > If LIBVIRT_DEBUG is set to a plain integer, or log level
> > string, then it will turn on logging for the "libvirt" log
> > category at that level. Any other string will be parsed in
> > the same way as LIBVIRT_LOG_FILTERS would be. In all cases
> > use of LIBVIRT_DEBUG will result in an explicit output being
> > added for stderr. This ensures that messages always go to
> > stderr, even if other outputs are already configured.
> > 
> > IOW,   LIBVIRT_DEBUG=1 virsh or LIBVIRT_DEBUG=1 libvirtd
> > will both result in printing logs of libvirt public API
> > calls to stderr. Meanwhile setting LIBVIRT_DEBUG="1:qemu"
> > is equivalent to setting LIBVIRT_LOG_FILTERS="1:qemu" and
> > LIBVIRT_LOG_OUTPUTS="1:stderr"
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

FYI, I'm still thinking about how to proceed with this patch
given the feedback so far....so consider this "on hold" until
I come up with a better idea.

In the meantime we must not make the problem worse. ie we should
*not* expose the default logging level config via the admin API.
Only expose log filters + outputs.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]