Red Hat Bugzilla – Bug 998482
guestfish remote prints "libguestfs: error: waitpid (qemu): No child processes"
Last modified: 2013-08-19 08:59:00 EDT
Reported by: Kazuya Saito
Note for some reason that I cannot work out, this is only reproducible
in the libguestfs source directory.
(a) Checkout libguestfs from git and compile it in the usual way.
(b) make -C tests/guests check
(c) In one window, run:
./run ./fish/guestfish --listen --ro -a ./tests/guests/debian.img -i
This will print out (the number will be different):
GUESTFISH_PID=13170; export GUESTFISH_PID
(d) In another window, run:
GUESTFISH_PID=13170 ./run ./fish/guestfish --remote exit
In the first window you'll see an error:
libguestfs: error: waitpid (qemu): No child processes
That is a bug.
Firstly the description is wrong. This *does* happen to a
regular installed guestfish. You don't need to compile anything
from source. However you *do* need to set LIBGUESTFS_BACKEND=direct:
LIBGUESTFS_BACKEND=direct guestfish --listen --ro -a debian.img -i -v
The bug only affects the 'direct' (run qemu directly) backend, not
the libvirt backend.
Normally libguestfs [when using the direct backend] forks qemu
and is the parent of the qemu process. Hence when libguestfs
cleans up qemu it can safely do:
kill (g->pid, SIGTERM);
waitpid (g->pid, NULL, 0);
However when using guestfish --remote, guestfish itself forks
into the background so it is no longer the parent of qemu (the
parent process exits, so qemu's parent reverts to init).
Because qemu is not a child of guestfish this has two effects:
(a) qemu is cleaned up by init when it exits, and
(b) the call to waitpid will return ECHILD ("No child processes").
I think the thing to do is to ignore ECHILD. It's not ideal, but
it's the best we can do under the circumstances.
Fixed upstream (slightly better than proposed in comment 1):