diff --git a/docs/logging.html b/docs/logging.html index b16a7bb42343d60fe27febbb7b1000836b0e27b7..0a11c274f63f54ec922c8a4fce96f71d97f5cabd 100644 --- a/docs/logging.html +++ b/docs/logging.html @@ -147,24 +147,42 @@
Note that, for example, setting LIBVIRT_DEBUG= is the same as unset. If + you specify an invalid value, it will be ignored with a warning. If you + have an error in a filter or output string, some of the settings may be + applied up to the point at which libvirt encountered the error.
Similary the daemon logging behaviour can be tuned using 3 config variables, stored in the configuration file:
In both case the syntax for filters and outputs is similar.
+When starting the libvirt daemon, any logging environment variable + settings will override settings in the config file. Command line options + take precedence over all. If no outputs are defined for libvirtd, it + defaults to logging to syslog when it is running as a daemon, or to + stderr when it is running in the foreground.
+Libvirtd does not reload its logging configuration when issued a SIGHUP.
+ If you want to reload the configuration, you must do a service
+ libvirtd restart
or manually stop and restart the daemon
+ yourself.
The syntax for filters and outputs is the same for both types of + variables.
The format for a filter is:
x:name
where name
is a match string e.g. remote
or
qemu
and the x is the minimal level where matching messages
should be logged:
Multiple filter can be defined in a single string, they just need to be +
Multiple filters can be defined in a single string, they just need to be
separated by spaces, e.g: "3:remote 4:event"
to only get
warning or errors from the remote layer and only errors from the event
layer.
+
If you specify a log priority in a filter that is below the default log + priority level, messages that match that filter will still be logged, + while others will not. In order to see those messages, you must also have + an output defined that includes the priority level of your filter.
The format for an output can be one of those 3 forms:
x:stderr
output goes to stderrx:syslog:name
use syslog for the output and use the
given name
as the identx:file:file_path
output to a file, with the given
diff --git a/docs/logging.html.in b/docs/logging.html.in
index fcd100ff528612e8b333bd1aa85f87b88b259da3..63a0b052e04096ec014e04a0ecc865ab4684db53 100644
--- a/docs/logging.html.in
+++ b/docs/logging.html.in
@@ -44,6 +44,10 @@
Note that, for example, setting LIBVIRT_DEBUG= is the same as unset. If + you specify an invalid value, it will be ignored with a warning. If you + have an error in a filter or output string, some of the settings may be + applied up to the point at which libvirt encountered the error.
Similary the daemon logging behaviour can be tuned using 3 config variables, stored in the configuration file:
In both case the syntax for filters and outputs is similar.
+When starting the libvirt daemon, any logging environment variable + settings will override settings in the config file. Command line options + take precedence over all. If no outputs are defined for libvirtd, it + defaults to logging to syslog when it is running as a daemon, or to + stderr when it is running in the foreground.
+Libvirtd does not reload its logging configuration when issued a SIGHUP.
+ If you want to reload the configuration, you must do a service
+ libvirtd restart
or manually stop and restart the daemon
+ yourself.
The syntax for filters and outputs is the same for both types of + variables.
The format for a filter is:
x:name
where name
is a match string e.g. remote
or
@@ -69,10 +83,14 @@
Multiple filter can be defined in a single string, they just need to be +
Multiple filters can be defined in a single string, they just need to be
separated by spaces, e.g: "3:remote 4:event"
to only get
warning or errors from the remote layer and only errors from the event
layer.
+
If you specify a log priority in a filter that is below the default log + priority level, messages that match that filter will still be logged, + while others will not. In order to see those messages, you must also have + an output defined that includes the priority level of your filter.
The format for an output can be one of those 3 forms:
x:stderr
output goes to stderr