[libvirt] [PATCH] (failed) virConnectOpenAuth: Add VIR_CONNECT_NO_DEFAULT_ERROR_HANDLER flag.
Well, it was a good idea, but the patch doesn't work. Apparently along their open paths, drivers don't set errors in the newly created handle, but in the global handler instead (hence the errors still get printed to stderr). How much I hate virterror ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On 10/14/2012 01:52 PM, Richard W.M. Jones wrote:
Well, it was a good idea, but the patch doesn't work. Apparently along their open paths, drivers don't set errors in the newly created handle, but in the global handler instead (hence the errors still get printed to stderr).
Can you give an example of the error you are seeing? I don't think I've ever experienced that issue with virt-install/virt-manager. You can use virSetErrorFunc before getting a virConnect handle. - Cole
On Sun, Oct 14, 2012 at 07:57:02PM -0400, Cole Robinson wrote:
On 10/14/2012 01:52 PM, Richard W.M. Jones wrote:
Well, it was a good idea, but the patch doesn't work. Apparently along their open paths, drivers don't set errors in the newly created handle, but in the global handler instead (hence the errors still get printed to stderr).
Can you give an example of the error you are seeing?
I was one of the libssh errors, I don't have the exact text.
I don't think I've ever experienced that issue with virt-install/virt-manager. You can use virSetErrorFunc before getting a virConnect handle.
You can do this in a program, but not in a library (like libguestfs) because it changes the global handler, which the program using the library might not be happy about. Doing it on a thread-local basis might work, but AFAICT from the source, only the error messages (not the handler) are thread-local. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Mon, Oct 15, 2012 at 08:43:44AM +0100, Richard W.M. Jones wrote:
On Sun, Oct 14, 2012 at 07:57:02PM -0400, Cole Robinson wrote:
On 10/14/2012 01:52 PM, Richard W.M. Jones wrote:
Well, it was a good idea, but the patch doesn't work. Apparently along their open paths, drivers don't set errors in the newly created handle, but in the global handler instead (hence the errors still get printed to stderr).
Can you give an example of the error you are seeing?
I was one of the libssh errors, I don't have the exact text.
I don't think I've ever experienced that issue with virt-install/virt-manager. You can use virSetErrorFunc before getting a virConnect handle.
You can do this in a program, but not in a library (like libguestfs) because it changes the global handler, which the program using the library might not be happy about.
Doing it on a thread-local basis might work, but AFAICT from the source, only the error messages (not the handler) are thread-local.
The error function callbacks in libvirt are rather horrible things that I wish we never had. I agree that libraries should not be explicitly setting it to a value of their owning choosing since that would override a setting an app might have made. I would think we could at least allow an env variable to turn off use of the default though. eg we could allow anyone to do export LIBVIRT_DEFAULT_ERROR_PRINT=0 and this would stop all use of virDefaultErrorFunc globally. THen libguestfs could set this env var, but apps would still be able to set a custom error function if they desired. 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 :|
On Mon, Oct 15, 2012 at 04:07:35PM +0100, Daniel P. Berrange wrote:
I would think we could at least allow an env variable to turn off use of the default though. eg we could allow anyone to do
export LIBVIRT_DEFAULT_ERROR_PRINT=0
and this would stop all use of virDefaultErrorFunc globally. THen libguestfs could set this env var, but apps would still be able to set a custom error function if they desired.
Unfortunately, how to set environment variables per-thread? I don't think it's possible (but please correct me if I'm wrong). The same problem also affects the autostart thing (RHBZ#865464#c9). BTW today I solved much the same problem in libguestfs: https://github.com/libguestfs/libguestfs/commit/9466060201600db47016133d80af... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Richard W.M. Jones