[libvirt] [PATCH 0/2] Last debug buffer patches: locking and docs
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
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@redhat.com> --- src/util/logging.c | 44 ++++++++++++++++++++++++++++++-------------- 1 files changed, 30 insertions(+), 14 deletions(-)
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
* 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@redhat.com> --- docs/logging.html.in | 64 ++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 60 insertions(+), 4 deletions(-)
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (2)
-
Daniel Veillard -
Eric Blake