From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19460 invoked from network); 29 Aug 1999 18:42:44 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Aug 1999 18:42:44 -0000 Received: (qmail 8975 invoked by alias); 29 Aug 1999 18:42:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7529 Received: (qmail 8968 invoked from network); 29 Aug 1999 18:42:31 -0000 From: "Bart Schaefer" Message-Id: <990829184215.ZM4413@candle.brasslantern.com> Date: Sun, 29 Aug 1999 18:42:15 +0000 In-Reply-To: <19990829033516.A27751@rom.oit.gatech.edu> Comments: In reply to Will Day "prob: fg not sending CONT to 'make' children" (Aug 29, 3:35am) References: <19990829033516.A27751@rom.oit.gatech.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: Will Day , zsh workers mailing list Subject: Re: prob: fg not sending CONT to 'make' children MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 29, 3:35am, Will Day wrote: } Subject: prob: fg not sending CONT to 'make' children } } I ran into the following problem under 3.1.6 while doing a recompile; after } stopping (ctrl-Z) the make process, doing an 'fg' would not continue the } make process. Looking at the process tree, the make itself is continued, } but its child process is still stopped. There seems to be something wrong in signals.c:killjb(). } Another datapoint is that I generally use a shell function to run make; if } I _don't_ use the function, it works properly. I'm able to reproduce this in both 3.0.6 and 3.1.6-pws-1 on my linux box, using exactly this function: } % gm() {gmake $*} I was able to continue the make by running `ps' to get the gmake process ID (in my case it was 2888) and then running kill -CONT -2888 && fg Note the negated PID, which turns the kill() into a killpg(). So gmake is a process group leader, though whether it did that itself or zsh did it, I'm not entirely sure; but I tend to "blame" zsh because 3.0.5 and 3.1.5 do not have the same problem. I think this must be a case where process group management was updated elsewhere but the change was not reflected in killjb(). The following patch resumes the make properly in this particular example, but I'm not sure it isn't an over-use of killpg() -- Sven, can you comment? Index: Src/signals.c =================================================================== @@ -591,7 +591,7 @@ if (jn->stat & STAT_SUPERJOB) { if (sig == SIGCONT) { for (pn = jobtab[jn->other].procs; pn; pn = pn->next) - kill(pn->pid, sig); + killpg(pn->pid, sig); for (pn = jn->procs; pn->next; pn = pn->next) err = kill(pn->pid, sig); -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com