On Tue, Apr 29, 2014 at 06:19:56PM +0200, Martin Kletzander wrote: > Hi everyone, > > after upgrade to gnutls-3.3.0, I discovered (commandtest fails) that > any code linked with -lgnutls will have not 3, but 5 open file > descriptors upon the entry into main(). I asked on gnutls-help [1] if > they know they are leaking file descriptors. The response was, that > this is intended with the explanation being that these FDs (pointing > to /dev/urandom) are kept open for backward compatibility with > programs that may chroot into environment without /dev/urandom as the > previous version didn't require to have access to /dev/urandom when > calling gnutls code. > > Does that seem like our bug that we're relying on fixed number of open > file descriptors? Or that we're linking to gnutls when we don't need > it in commandhelper? Or should this be fixed somewhere else? Hmm, before considering the test suite - what is the behaviour when we use virCommand for real. ie if we launch QEMU, is gnutls causing us to leak a /dev/urandom FD to QEMU ? Or is the fact that we iterate over all FDs forcing them to be close saving us. IMHO it is really dubious that GNUTLS would open file descriptors in a library constructor function :-( 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