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): https://github.com/libguestfs/libguestfs/commit/a843b5e5e32c151e7b0c74bb4f7be1030f9ac85b