2:41 a.m.
That's the remaining changes left for the debug buffer.
The first patch is the one removing locking in the signal
error handler. As discussed it's better to have a risk of
slightly corrupted output in the log dump than have a risk
crashing due to the unsafe locking operations in the
signal handler.
The second patch documents the debug buffer changes and
improve the logging page to add more structure, and more
examples.
Daniel
2:41 a.m.
New subject: [libvirt] [PATCH 1/2] Avoid taking lock in libvirt debug dump
As pointed out, locking the buffer from the signal handler
cannot been garanteed to be safe, so to avoid any hazard
we prefer the trade off of dumping logs possibly messed up
by concurrent logging activity rather than risk a daemon
crash.
* src/util/logging.c: change virLogEmergencyDumpAll() to not
take any lock on the log buffer but reset buffer content variables
to an empty set before starting the actual dump.
Signed-off-by: Daniel Veillard <veillard(a)redhat.com>
---
src/util/logging.c | 44 ++++++++++++++++++++++++++++++--------------
1 files changed, 30 insertions(+), 14 deletions(-)
6:19 p.m.
New subject: [libvirt] [PATCH 1/2] Avoid taking lock in libvirt debug dump
On 03/17/2011 01:41 AM, Daniel Veillard wrote:
As pointed out, locking the buffer from the signal handler
cannot been garanteed to be safe, so to avoid any hazard
s/garanteed/guaranteed/
we prefer the trade off of dumping logs possibly messed up
by concurrent logging activity rather than risk a daemon
crash.
* src/util/logging.c: change virLogEmergencyDumpAll() to not
take any lock on the log buffer but reset buffer content variables
+ /*
+ * Since we can't lock the buffer safely from a signal
handler
+ * we mark it as empty in case of concurrent access, and proceed
+ * with the data, at worse we will output something a bit weird
+ * if another thread start logging messages at the same time.
+ * Note that virLogStr() uses virLogEnd for the computations and
+ * writes to the buffer and then only update virLogLen and virLogStart
s/then only update/only then updates/
ACK with those nits fixed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
2:41 a.m.
New subject: [libvirt] [PATCH 2/2] Improve logging documentation including the debug buffer
* docs/logging.html.in: document the fact that starting from
0.9.0 the server logs goes to libvirtd.log instead of syslog
by default, describe the debug buffer, restructure the page
and add a couple more examples
Signed-off-by: Daniel Veillard <veillard(a)redhat.com>
---
docs/logging.html.in | 64 ++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 60 insertions(+), 4 deletions(-)
6:25 p.m.
New subject: [libvirt] [PATCH 2/2] Improve logging documentation including the debug buffer
On 03/17/2011 01:41 AM, Daniel Veillard wrote:
* docs/logging.html.in: document the fact that starting from
0.9.0 the server logs goes to libvirtd.log instead of syslog
by default, describe the debug buffer, restructure the page
and add a couple more examples
- <li>log messages: they are information generated at
runtime by
+ <li><b>log messages</b>: they are information generated at
runtime by
the libvirt code. Each message includes a priority level (DEBUG = 1,
INFO = 2, WARNING = 3, ERROR = 4), a category, function name and
line number, indicating where it originated from, and finally
a formatted message. In addition the library adds a timestamp
at the begining of the message</li>
While you're here:
s/begining/beginning/
- <li>log filt> + <p>Note that the logging
module saves all logs to a <b>debug buffer</b>
+ filled in a round-robin fashion as to keep a full log of the
+ recent logs including all debug. The debug buffer can be resized
+ or deactivated in the daemon using the log_buffer_size variable,
+ default is 64 kB. This can be used when debugging the libvrary
s/libvrary/library/
+ <p>Starting from 0.9.0, the daemon can save all the
content of the debug
+ buffer to the defined error channels (or /var/log/libvirt/libvirtd.log
+ by default) in case of crash, this can also be activated explicitely
s/explicitely/explicitly/
+ for debugging purposes by sending the daemon an USR2
signal:</p>
s/an USR2/a USR2/
@@ -111,6 +153,9 @@
will log all warnings and errors to syslog under the libvirtd ident
but also log everything debugging and informations included in the
While we're here: s/log everything debugging and informations/log all
debug and information/
what is happening and where things are going wrong, allowing to
then
put the correct breakpoints when running under a debugger.</p>
+ <p>To activate full debug of the libvirt entry points, utilities
+ functions and the QEmu/KVM driver, setting:</p>
s/utilities functions/utility functions/
s/setting:/set:/
+ <pre>log_filters=1:libvirt 1:util 1:qemu
+log_output=1:file:/var/log/libvirt/libvirtd.log</pre>
+ <p>in the libvirtd.conf and restarting the daemon will allow to
+ gather a copious amount of debugging traces for the operations done
+ in those areas.</p>
+ <p>On the other hand to deactivate the logbuffer in the daemon
+ for stable high load servers, set</p>
+ <pre>log_buffer_size=0</pre>
+ <p>in the libvirtd.conf.</p>
s/in the/in/
ACK with those nits fixed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
9:17 p.m.
New subject: [libvirt] [PATCH 2/2] Improve logging documentation including the debug buffer
On Thu, Mar 17, 2011 at 05:25:53PM -0600, Eric Blake wrote:
On 03/17/2011 01:41 AM, Daniel Veillard wrote:
> * docs/logging.html.in: document the fact that starting from
> 0.9.0 the server logs goes to libvirtd.log instead of syslog
> by default, describe the debug buffer, restructure the page
> and add a couple more examples
> - <li>log messages: they are information generated at runtime by
> + <li><b>log messages</b>: they are information generated at
runtime by
> the libvirt code. Each message includes a priority level (DEBUG = 1,
> INFO = 2, WARNING = 3, ERROR = 4), a category, function name and
> line number, indicating where it originated from, and finally
> a formatted message. In addition the library adds a timestamp
> at the begining of the message</li>
While you're here:
s/begining/beginning/
> - <li>log filt> + <p>Note that the logging module saves all
logs to a <b>debug buffer</b>
> + filled in a round-robin fashion as to keep a full log of the
> + recent logs including all debug. The debug buffer can be resized
> + or deactivated in the daemon using the log_buffer_size variable,
> + default is 64 kB. This can be used when debugging the libvrary
s/libvrary/library/
> + <p>Starting from 0.9.0, the daemon can save all the content of the debug
> + buffer to the defined error channels (or /var/log/libvirt/libvirtd.log
> + by default) in case of crash, this can also be activated explicitely
s/explicitely/explicitly/
> + for debugging purposes by sending the daemon an USR2 signal:</p>
s/an USR2/a USR2/
> @@ -111,6 +153,9 @@
> will log all warnings and errors to syslog under the libvirtd ident
> but also log everything debugging and informations included in the
While we're here: s/log everything debugging and informations/log all
debug and information/
> what is happening and where things are going wrong, allowing to then
> put the correct breakpoints when running under a debugger.</p>
> + <p>To activate full debug of the libvirt entry points, utilities
> + functions and the QEmu/KVM driver, setting:</p>
s/utilities functions/utility functions/
s/setting:/set:/
> + <pre>log_filters=1:libvirt 1:util 1:qemu
> +log_output=1:file:/var/log/libvirt/libvirtd.log</pre>
> + <p>in the libvirtd.conf and restarting the daemon will allow to
> + gather a copious amount of debugging traces for the operations done
> + in those areas.</p>
> + <p>On the other hand to deactivate the logbuffer in the daemon
> + for stable high load servers, set</p>
> + <pre>log_buffer_size=0</pre>
> + <p>in the libvirtd.conf.</p>
s/in the/in/
ACK with those nits fixed.
Heh, thanks for all the fixes :-)
Applied and pushed both !
BTW I'm clearly not a native english speaker, but "a USR2 signal" sounds
strange to me, or rather hard to pronounce, and I would have assumed that
"an" would have to be used even with an acronym, or maybe there is a
different reason :)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:10 a.m.
New subject: [libvirt] [PATCH 2/2] Improve logging documentation including the debug buffer
On 03/17/2011 08:17 PM, Daniel Veillard wrote:
>> + for debugging purposes by sending the daemon an USR2
signal:</p>
>
> s/an USR2/a USR2/
>
BTW I'm clearly not a native english speaker, but "a USR2 signal" sounds
strange to me, or rather hard to pronounce, and I would have assumed that
"an" would have to be used even with an acronym, or maybe there is a
different reason :)
Whether you pronounce it "user-two" or "you-ess-are-two', the point is
that the signal name starts with a voiced 'y' sound. The general rule
in English is that you use 'a' before a voiced sound, 'an' before an
unvoiced vowel ('a yellow object', 'a user', 'an update').
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
5028
days inactive
5029
days old
6 comments
2 participants
participants (2)
-
Daniel Veillard -
Eric Blake