On Thu, Nov 03, 2011 at 09:41:40PM -0400, Chris Lalancette wrote:
Hey Rich,
In the past I know you have mentioned that using
guestfs.kill_subprocess() isn't strictly necessary after you are finished
using libguestfs. I believe you said that in the python bindings, that
step would happen automatically when the object goes out of scope and the
__del__ method is called. However, since it never seemed to harm anything
and I wanted to be extra safe, I always called guestfs.kill_subprocess() in
Oz, without apparent harm.
Python bindings now have an explicit close call:
8c5bdc3e12947580e91c018b71adf9ad3128bb75
http://bugzilla.redhat.com/717786
However, Richard Su has been investigating an issue where
guestfs.kill_subprocess() actually does cause harm. I believe the
situation is that running Oz (and hence libguestfs) simultaneously from two
threads in the same process causes the entire process to hang. If we
remove the guestfs.kill_subprocess(), the problem goes away. rwsu, can you
please fill in a bit more detail here, as I'm not intimately familiar with
the issue? Things like host OS, libguestfs version, etc etc would be
helpful. Also confirmation that the problem is indeed in the
multi-threaded environment of the image factory like I think it is.
rjones, do you have any ideas here? I'm going to merge rwsu's patch
to remove the call to kill_subprocess(), but I thought it would be worth a
little more digging into why it was happening.
You could be hitting this bug:
http://bugzilla.redhat.com/684980
To debug this I need to see:
- version of libguestfs
- platform that you're running it on
- full output with LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 set
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v