Bug 998482 - guestfish remote prints "libguestfs: error: waitpid (qemu): No child processes"
guestfish remote prints "libguestfs: error: waitpid (qemu): No child processes"
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard W.M. Jones
: OtherQA
Depends On:
Blocks: 839484 996825 998485
  Show dependency treegraph
Reported: 2013-08-19 08:30 EDT by Richard W.M. Jones
Modified: 2013-08-19 08:59 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 996825
: 998485 (view as bug list)
Last Closed: 2013-08-19 08:59:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2013-08-19 08:30:45 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):


(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.
Comment 1 Richard W.M. Jones 2013-08-19 08:47:29 EDT
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.
Comment 2 Richard W.M. Jones 2013-08-19 08:59:00 EDT
Fixed upstream (slightly better than proposed in comment 1):

Note You need to log in before you can comment on or make changes to this bug.