New APIs: set-pgroup, get-pgroup

If the pgroup flag is set in the handle, then the qemu and recovery
subprocesses are placed in separate process groups.  The default is
false.

The purpose for setting up a process group is that ^C will not be
passed from the main process down to these processes (killing them).
This allows ^C and other keyboard events to be caught and handled in
the main process.

1 files changed, 11 insertions, 6 deletions

diff --git a/src/launch.c b/src/launch.c
index 0b15ce98..1a47363d 100644
--- a/src/launch.c
+++ b/src/launch.c
@@ -643,12 +643,9 @@ launch_appliance (guestfs_h *g)
       close (rfd[1]);
     }
 
-#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
+    /* Put qemu in a new process group. */
+    if (g->pgroup)
+      setpgid (0, 0);
 
     setenv ("LC_ALL", "C", 1);
 
@@ -677,6 +674,14 @@ launch_appliance (guestfs_h *g)
       pid_t qemu_pid = g->pid;
       pid_t parent_pid = getppid ();
 
+      /* It would be nice to be able to put this in the same process
+       * group as qemu (ie. setpgid (0, qemu_pid)).  However this is
+       * not possible because we don't have any guarantee here that
+       * the qemu process has started yet.
+       */
+      if (g->pgroup)
+        setpgid (0, 0);
+
       /* Writing to argv is hideously complicated and error prone.  See:
        * http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/ps_status.c?rev=1.33.2.1;content-type=text%2Fplain
        */