[ On Friday, April 2, 1999 at 11:43:19 (-0500), Mason Loring Bliss wrote: ]
> Subject: Re: killing a package make
>
> > Should it not be possible to hit ctrl-c to kill the parent and all child
> > processes of the make?
> 
> Yes. I always thought that's what happened... <boggle>

I'm not 100% sure why this doesn't always work as expected, but I do
find the following in make's sources (job.c), and I don't think that
USE_PGRP is normally defined by default:

#ifdef USE_PGRP
        /*
         * We want to switch the child into a different process family so
         * we can kill it and all its descendants in one fell swoop,
         * by killing its process family, but not commit suicide.
         */
    .
    .
    .
        (void) setpgid(0, getpid());
    .
    .
    .
#endif

If USE_PGRP were defined then make would use killpg() to signal its
children instead of just kill(), and since the above makes every direct
child job into a process group leader, all sub-jobs should die too
(unless the child process does something stupid with signals).

Perhaps USE_PGRP should be defined by default, esp. on 4.4BSDs?

Note that the real mess with signals and make comes from the fact that
make does not catch any POSIX signal that have been ignored (which is
indeed appropriate for it to do).  This means that if you run make in
the background under certain shells then you cannot shut it down cleanly
and expect all of its children to die too.  I think this is *bad*, but
it's been that way for a while, and it's not make's fault -- the problem
is in those shells which cause it....

Reading through some of the code reminds me -- what about getting the
#ifdef REMOTE stuff working?  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>