From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20690 invoked from network); 6 May 2000 19:57:59 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 May 2000 19:57:59 -0000 Received: (qmail 25555 invoked by alias); 6 May 2000 19:57:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11239 Received: (qmail 25515 invoked from network); 6 May 2000 19:57:47 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: fg/bg on FreeBSD. References: <1000506170828.ZM2063@candle.brasslantern.com> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII From: Tanaka Akira Date: 07 May 2000 04:58:47 +0900 In-Reply-To: (Tanaka Akira's message of "07 May 2000 02:48:42 +0900") Message-ID: User-Agent: T-gnus/6.14.1 (based on Gnus v5.8.3) (revision 16) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN) In article , Tanaka Akira writes: > Possibly. But NetBSD has no problem... I found the difference between FreeBSD and NetBSD. FreeBSD fails to kill(-PGID,0) for zombie process but NetBSD (and Linux) succeeds. FreeBSD: > | Z:akr@dhcp21% kdump|egrep 'kill|fork|exit|setpgid' > | 29256 zsh CALL fork # zsh: fork for echo > | 29256 zsh RET fork 29257/0x7249 > | 29257 zsh RET fork 0 > | 29257 zsh CALL setpgid(0,0x7249) # echo: setpgid(0,29257) > | 29257 zsh RET setpgid 0 > | 29256 zsh CALL fork # zsh: fork for sleep > | 29256 zsh RET fork 29258/0x724a > | 29257 zsh CALL exit(0) # echo: exit(0) 29257(echo) is zombie now. > | 29258 zsh RET fork 0 > | 29258 zsh CALL kill(0xffff8db7,0) > | 29258 zsh RET kill -1 errno 3 No such process The process to be sleep command tries to check a leader is exists... 0xffff8db7 is -29257. kill(-29257,0) is failed. > | 29258 zsh CALL setpgid(0,0x724a) # sleep: setpgid(0,29258) > | 29258 zsh RET setpgid 0 So, it decides to be a leader itself. NetBSD: > | Z:akr@netbsd% kdump|egrep 'kill|fork|exit|setpgid' > | 16519 zsh CALL fork # zsh: fork for echo > | 16519 zsh RET fork 16520/0x4088 > | 16520 zsh RET fork 0 > | 16520 zsh CALL setpgid(0,0x4088) > | 16520 zsh RET setpgid 0 > | 16520 zsh CALL exit(0) # echo: exit(0) 16520(echo) is zombie now. > | 16519 zsh CALL fork # zsh: fork for sleep > | 16519 zsh RET fork 16521/0x4089 > | 16521 zsh RET fork 0 > | 16521 zsh CALL kill(0xffffbf78,0) > | 16521 zsh RET kill 0 The process to be sleep command tries to check a leader is exists... 0xffffbf78 is -16520. kill(-16520,0) is succeed. > | 16521 zsh CALL setpgid(0,0x4088) # sleep: setpgid(0,16520) > | 16521 zsh RET setpgid 0 So, it comes into the process group of echo. I confirmed following modification prevents the problem. But definitely this is too radical... Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.7 diff -u -r1.7 exec.c --- Src/exec.c 2000/05/04 13:40:05 1.7 +++ Src/exec.c 2000/05/06 19:53:20 @@ -2466,7 +2466,7 @@ } } else if (thisjob != -1 && cl) { if (jobtab[list_pipe_job].gleader && (list_pipe || list_pipe_child)) { - if (killpg(jobtab[list_pipe_job].gleader, 0) == -1 || + if (/* killpg(jobtab[list_pipe_job].gleader, 0) == -1 || */ setpgrp(0L, jobtab[list_pipe_job].gleader) == -1) { jobtab[list_pipe_job].gleader = jobtab[thisjob].gleader = (list_pipe_child ? mypgrp : getpid()); -- Tanaka Akira