Libguestfs - Mar 2011 - setpgid() before exec'ing qemu

Hi

I am writing a python test suite that uses oz
(https://github.com/clalancette/oz)
which uses libquestfs. I am simulating a small cloud and have some apps that
need
to talk to the guests.

All works really well until I needed to start another process.
So I start a process then "oz" starts up a VM (it uses libquestfs)
then when "oz" cleans up it calls libquestfs.kill_subprocess().
At this point my test locks up.

A bacetrace of the python code is:
#0  0x00000036fe80ef1e in waitpid () from /lib64/libpthread.so.0
#1  0x0000003629c0df7f in guestfs_close () from /usr/lib64/libguestfs.so.0
then a mess of python stuff

If I attach to it with strace it shows:
wait4(0,

It looks like libguestfs's children are already dead
pstree 13107
python???cped???3*[{cped}]
       ??qpidd???9*[{qpidd}]

so it's seems like it's waiting on my process to die.

So I changed the oz code to call close (in python "del obj") and all
is well,
however I was looking in libquestfs code and saw:
#if 0
    /* Set up a new process group, so we can signal this process
     * and all subprocesses (eg. if qemu is really a shell script).
     */
   setpgid (0, 0);
#endif

Any reason this is "if def'ed" out?
this was done in commit 88f69eb03160a62d38 
I was thinking this might prevent my problem from occuring in the first place?


Chris:
Any special reason you are using kill_subprocess()?
    def kill_subprocess (self):
         u"""This kills the qemu subprocess. You should never
need to
          call this.
         """
         return libguestfsmod.kill_subprocess (self._o)
                                    

Regards
Angus Salkeld

On Fri, Mar 11, 2011 at 12:56:43PM +1100, Angus Salkeld
wrote:
> Hi
> 
> I am writing a python test suite that uses oz
(https://github.com/clalancette/oz)
> which uses libquestfs. I am simulating a small cloud and have some apps
that need
> to talk to the guests.
> 
> All works really well until I needed to start another process.
> So I start a process then "oz" starts up a VM (it uses
libquestfs)
> then when "oz" cleans up it calls libquestfs.kill_subprocess().
> At this point my test locks up.
As Chris says, any reason to be using kill_subprocess at all?  You can
just delete the handle which has the same effect (and is a much more
well-tested path).  Something like:

  del g
> A bacetrace of the python code is:
> #0  0x00000036fe80ef1e in waitpid () from /lib64/libpthread.so.0
> #1  0x0000003629c0df7f in guestfs_close () from /usr/lib64/libguestfs.so.0
> then a mess of python stuff
> 
> If I attach to it with strace it shows:
> wait4(0,
> 
> It looks like libguestfs's children are already dead
> pstree 13107
> python???cped???3*[{cped}]
>        ??qpidd???9*[{qpidd}]
> 
> so it's seems like it's waiting on my process to die.
> 
> So I changed the oz code to call close (in python "del obj") and
all is well,
> however I was looking in libquestfs code and saw:
> #if 0
>     /* Set up a new process group, so we can signal this process
>      * and all subprocesses (eg. if qemu is really a shell script).
>      */
>    setpgid (0, 0);
> #endif
> 
> Any reason this is "if def'ed" out?
> this was done in commit 88f69eb03160a62d38 
> I was thinking this might prevent my problem from occuring in the
> first place?
I don't know why exactly waitpid isn't working, but I doubt it's
anything to do with the (lack of) a process group.

Are you using a qemu wrapper script?

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