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