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