On Fri, Mar 11, 2011 at 05:43:52PM +0000, Richard W.M. Jones wrote:
On Fri, Mar 11, 2011 at 05:26:50PM +0000, Richard W.M. Jones wrote:
> As Chris says, any reason to be using kill_subprocess at all?
Actually as Chris *didn't* say, I was reading that wrong :-)
Anyway, I'd try deleting the handle. AFAIK Python will run the
destructor immediately, and the path taken via guestfs_close certainly
kills the subprocess:
http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/guestfs.c;h=8b7ab4d...
If you're really worried about the subprocess staying around, then
grab the PID (g.get_pid) and kill the process *after* deleting the
handle. (This is way outside the scope of the API ...)
We could do this but I
think there is a little bug in libguestfs
that we can easily fix.
Attached is a simple python test case that fails for me.
I believe that the kill_subprocess() is killing what it should
then guestfs_close() is getting run again because "del g" calls
obj.__del__() and that calls guestfs_close().
It this code there is a waitpid() without a check to see if the
pid is > 0.
(I'll reply to this email with a patch)
Can someone (with a libguestfs that builds) test this?
I have been having problems setting up a libguestfs that can build
else I'de test this my self.
Thanks
Angus Salkeld
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