From: "Richard W.M. Jones" <rjones@redhat.com> When using guestfish --remote, libguestfs is not the parent of qemu, so waitpid is expected to return -ECHILD. And indeed guestfish --remote would print a bogus error message in this case: libguestfs: error: waitpid (qemu): No child processes If the parent process forked into the background, then it should have called 'set_recovery_proc 0' so we can use this to determine if we need to wait for qemu. Thanks: Kazuya Saito for reporting and identifying the issue. (cherry picked from commit a843b5e5e32c151e7b0c74bb4f7be1030f9ac85b) (cherry picked from commit 8b354dbbfd412c860fb65c7674fe1f25059e3a31) --- src/launch-appliance.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/launch-appliance.c b/src/launch-appliance.c index 69c4145..bb9c832 100644 --- a/src/launch-appliance.c +++ b/src/launch-appliance.c @@ -1044,7 +1044,7 @@ shutdown_appliance (guestfs_h *g, int check_for_errors) if (g->app.recoverypid > 0) kill (g->app.recoverypid, 9); /* Wait for subprocess(es) to exit. */ - if (g->app.pid > 0) { + if (g->recovery_proc /* RHBZ#998482 */ && g->app.pid > 0) { if (waitpid (g->app.pid, &status, 0) == -1) { perrorf (g, "waitpid (qemu)"); ret = -1; -- 1.8.3.1