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 :|