* Re: fg/bg on FreeBSD.
@ 2000-05-08 8:48 Sven Wischnowsky
2000-05-08 9:17 ` Tanaka Akira
0 siblings, 1 reply; 10+ messages in thread
From: Sven Wischnowsky @ 2000-05-08 8:48 UTC (permalink / raw)
To: zsh-workers
Tanaka Akira wrote:
> In article <1000506212352.ZM8935@candle.brasslantern.com>,
> "Bart Schaefer" <schaefer@candle.brasslantern.com> writes:
>
> > What happens if you reverse the order of the test?
> >
> > if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 ||
> > killpg(jobtab[list_pipe_job].gleader, 0) == -1) {
>
> Wow! It's good idea.
Indeed. Why no patch for this? In other words: have I missed something?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: fg/bg on FreeBSD. 2000-05-08 8:48 fg/bg on FreeBSD Sven Wischnowsky @ 2000-05-08 9:17 ` Tanaka Akira 0 siblings, 0 replies; 10+ messages in thread From: Tanaka Akira @ 2000-05-08 9:17 UTC (permalink / raw) To: zsh-workers In article <200005080848.KAA12669@beta.informatik.hu-berlin.de>, Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes: > > > if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 || > > > killpg(jobtab[list_pipe_job].gleader, 0) == -1) { > > > > Wow! It's good idea. > > Indeed. Why no patch for this? In other words: have I missed something? OK. This is the patch. (I'll commit this.) 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/08 09:15:31 @@ -2466,8 +2466,8 @@ } } 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 || - setpgrp(0L, jobtab[list_pipe_job].gleader) == -1) { + if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 || + killpg(jobtab[list_pipe_job].gleader, 0) == -1) { jobtab[list_pipe_job].gleader = jobtab[thisjob].gleader = (list_pipe_child ? mypgrp : getpid()); setpgrp(0L, jobtab[list_pipe_job].gleader); -- Tanaka Akira ^ permalink raw reply [flat|nested] 10+ messages in thread
* fg/bg on FreeBSD. @ 2000-05-06 15:03 Tanaka Akira 2000-05-06 17:08 ` Bart Schaefer 0 siblings, 1 reply; 10+ messages in thread From: Tanaka Akira @ 2000-05-06 15:03 UTC (permalink / raw) To: zsh-workers On FreeBSD 3.4 and 4.0, fg/bg may not activate suspended process. | Z:akr@dhcp21% ktrace zsh -f Start zsh with kernel trace. | dhcp21% echo|sleep 10 | ^Z | zsh: done echo | | zsh: suspended sleep 10 Start `echo|sleep 10' and immediately suspend it by <C-z>. | dhcp21% jobs -l | [1] + 754 done echo | | 755 suspended sleep 10 Report the job info. echo's PID is 754 and it's already done. sleep's PID is 755 and it's suspended. | dhcp21% ps j755 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 755 753 755 92fdc0 1 T p1 0:00.00 sleep 10 Check the process status by ps. `T' on `STAT' field shows that it's stopped. | dhcp21% bg | [1] + done echo | | continued sleep 10 Resume the job on a background. It seems resumed, but ... | dhcp21% ps j755 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 755 753 755 92fdc0 1 T p1 0:00.00 sleep 10 Check the process status by ps again. The process is not resumed. | dhcp21% kill -9 755 | [1] + done echo | | killed sleep 10 | dhcp21% exit kill the process and exit. | Z:akr@dhcp21% kdump|grep kill | 753 zsh CALL kill(0xfffffd0d,0) # kill(-755,0) | 753 zsh RET kill 0 | 753 zsh CALL kill(0xfffe7960,0) # kill(-100000,0) | 753 zsh RET kill -1 errno 3 No such process | 753 zsh CALL kill(0xfffffd0e,0x13) # kill(-754,SIGCONT) | 753 zsh RET kill -1 errno 3 No such process | 753 zsh CALL kill(0xfffe7960,0) # kill(-100000,0) | 753 zsh RET kill -1 errno 3 No such process | 753 zsh CALL kill(0x2f3,0x9) # kill(755,SIGKILL) | 753 zsh RET kill 0 | killed sleep 10 | Z:akr@dhcp21% There are `kill system call' called by zsh. I suppose the system call correspondding to the `bg' is `kill(-754,SIGCONT)'. It's failed because the process group 754 is not exist. I think it is wrong that the sleep process has process group 755 rather than 754. Because zsh assigns a process group as a process number of first component of a pipe. Note that if `fg' is used for resume the job, zsh hangs. -- Tanaka Akira ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 15:03 Tanaka Akira @ 2000-05-06 17:08 ` Bart Schaefer 2000-05-06 17:48 ` Tanaka Akira 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2000-05-06 17:08 UTC (permalink / raw) To: zsh-workers On May 7, 12:03am, Tanaka Akira wrote: } Subject: fg/bg on FreeBSD. } } On FreeBSD 3.4 and 4.0, fg/bg may not activate suspended process. } } Report the job info. } echo's PID is 754 and it's already done. } sleep's PID is 755 and it's suspended. } } | dhcp21% ps j755 } | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND } | akr 755 753 755 92fdc0 1 T p1 0:00.00 sleep 10 Here's the same on linux: zagzig[22] jobs -l [1] + 2052 done echo | 2053 suspended sleep 10 zagzig[23] ps j2053 PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND 2013 2053 2052 2013 pc 2054 T 674 0:00 sleep 10 Why is the PGID of sleep different on FreeBSD? Did it change after the sleep was started because the echo exited? Please try the same test, but replace "echo" with "sleep 9" so that you can stop both jobs before either one of them exits. Then see what the PGID of the second sleep is. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 17:08 ` Bart Schaefer @ 2000-05-06 17:48 ` Tanaka Akira 2000-05-06 18:45 ` Bart Schaefer 2000-05-06 19:58 ` Tanaka Akira 0 siblings, 2 replies; 10+ messages in thread From: Tanaka Akira @ 2000-05-06 17:48 UTC (permalink / raw) To: zsh-workers In article <1000506170828.ZM2063@candle.brasslantern.com>, "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: > Why is the PGID of sleep different on FreeBSD? Did it change after the > sleep was started because the echo exited? Possibly. But NetBSD has no problem... | Z:akr@dhcp21% ktrace -i zsh -f | dhcp21% echo|sleep 10 | ^Z | zsh: done echo | | zsh: suspended sleep 10 | dhcp21% jobs -l | [1] + 29257 done echo | | 29258 suspended sleep 10 | dhcp21% ps j29258 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29258 29256 29258 94d480 1 T p3 0:00.00 sleep 10 | dhcp21% bg | [1] + done echo | | continued sleep 10 | dhcp21% ps j29258 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29258 29256 29258 94d480 1 T p3 0:00.00 sleep 10 | dhcp21% kill -9 29258 | [1] + done echo | | killed sleep 10 | dhcp21% exit | 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) | 29258 zsh RET fork 0 | 29258 zsh CALL kill(0xffff8db7,0) | 29258 zsh RET kill -1 errno 3 No such process | 29258 zsh CALL setpgid(0,0x724a) # sleep: setpgid(0,29258) Hm. The process to be sleep command set its PGID itself. | 29258 zsh RET setpgid 0 | 29256 zsh CALL kill(0xffff8db6,0) | 29256 zsh RET kill 0 | 29256 zsh CALL fork # zsh: fork for ps | 29256 zsh RET fork 29259/0x724b | 29259 zsh RET fork 0 | 29259 zsh CALL setpgid(0,0x724b) | 29259 zsh RET setpgid 0 | 29259 ps CALL exit(0) | 29256 zsh CALL kill(0xfffe7960,0) | 29256 zsh RET kill -1 errno 3 No such process | 29256 zsh CALL kill(0xffff8db7,0x13) # zsh: kill(-29257,SIGCONT) | 29256 zsh RET kill -1 errno 3 No such process | 29256 zsh CALL fork # zsh: fork for ps | 29256 zsh RET fork 29260/0x724c | 29260 zsh RET fork 0 | 29260 zsh CALL setpgid(0,0x724c) | 29260 zsh RET setpgid 0 | 29260 ps CALL exit(0) | 29256 zsh CALL kill(0xfffe7960,0) | 29256 zsh RET kill -1 errno 3 No such process | 29256 zsh CALL kill(0x724a,0x9) | 29256 zsh RET kill 0 | killed sleep 10 | 29256 zsh CALL exit(0) | Z:akr@dhcp21% > Please try the same test, but replace "echo" with "sleep 9" so that you > can stop both jobs before either one of them exits. Then see what the > PGID of the second sleep is. OK. | Z:akr@dhcp21% ktrace -i zsh -f | dhcp21% sleep 100|sleep 200 | ^Z | zsh: suspended sleep 100 | sleep 200 9 seconds are too short to check it... | dhcp21% jobs -l | [1] + 29245 suspended sleep 100 | | 29246 suspended sleep 200 | dhcp21% ps j29245; ps j29246 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29245 29244 29245 94d480 2 T p3 0:00.00 sleep 100 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29246 29244 29245 94d480 2 T p3 0:00.00 sleep 200 PGID is first sleep's PID. It's good. | dhcp21% bg | [1] + continued sleep 100 | sleep 200 | dhcp21% ps j29245; ps j29246 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29245 29244 29245 94d480 2 I p3 0:00.00 sleep 100 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29246 29244 29245 94d480 2 I p3 0:00.00 sleep 200 It's successfully resumed. | dhcp21% kill %1 | [1] + terminated sleep 100 | sleep 200 | dhcp21% exit | Z:akr@dhcp21% Note that this is the result of similar test on NetBSD. | Z:akr@netbsd% ktrace -i zsh -f | netbsd% echo|sleep 100 | ^Z | zsh: done echo | | zsh: suspended sleep 100 | netbsd% jobs -l | [1] + 16520 done echo | | 16521 suspended sleep 100 | netbsd% ps j16521 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 16521 16519 16520 c09fae40 1 T p1 0:00.01 sleep 100 | netbsd% bg | [1] + done echo | | continued sleep 100 | netbsd% ps j16521 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 16521 16519 16520 c09fae40 1 S p1 0:00.01 sleep 100 | netbsd% kill %1 | [1] + done echo | | terminated sleep 100 | netbsd% exit | 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) | 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 | 16521 zsh CALL setpgid(0,0x4088) # sleep: setpgid(0,16520) It setpgid itself to 16520(echo's PID) correctly. | 16521 zsh RET setpgid 0 | 16519 zsh CALL fork | 16519 zsh RET fork 16522/0x408a | 16522 zsh RET fork 0 | 16522 zsh CALL setpgid(0,0x408a) | 16522 zsh RET setpgid 0 | 16519 zsh CALL kill(0xffff8acf,0) | 16519 zsh RET kill -1 errno 3 No such process | 16519 zsh CALL kill(0xffffbf78,0x13) | 16519 zsh RET kill 0 | 16519 zsh CALL fork | 16519 zsh RET fork 16523/0x408b | 16523 zsh RET fork 0 | 16523 zsh CALL setpgid(0,0x408b) | 16523 zsh RET setpgid 0 | 16519 zsh CALL kill(0xffff8acf,0) | 16519 zsh RET kill -1 errno 3 No such process | 16519 zsh CALL kill(0xffffbf78,0xf) | 16519 zsh RET kill 0 | 16519 zsh CALL exit(0) | Z:akr@netbsd% -- Tanaka Akira ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 17:48 ` Tanaka Akira @ 2000-05-06 18:45 ` Bart Schaefer 2000-05-06 19:03 ` Tanaka Akira 2000-05-06 19:58 ` Tanaka Akira 1 sibling, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2000-05-06 18:45 UTC (permalink / raw) To: Tanaka Akira, zsh-workers On May 7, 2:48am, Tanaka Akira wrote: } Subject: Re: fg/bg on FreeBSD. } } In article <1000506170828.ZM2063@candle.brasslantern.com>, } "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: } } > Why is the PGID of sleep different on FreeBSD? Did it change after the } > sleep was started because the echo exited? } } Possibly. But NetBSD has no problem... Yes, what I'm wondering is whether this is a FreeBSD bug. } | Z:akr@dhcp21% ktrace -i zsh -f } | dhcp21% sleep 100|sleep 200 } | ^Z } | zsh: suspended sleep 100 | sleep 200 } | dhcp21% jobs -l } | [1] + 29245 suspended sleep 100 | } | 29246 suspended sleep 200 } | dhcp21% ps j29245; ps j29246 } | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND } | akr 29245 29244 29245 94d480 2 T p3 0:00.00 sleep 100 } | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND } | akr 29246 29244 29245 94d480 2 T p3 0:00.00 sleep 200 } } PGID is first sleep's PID. It's good. } } | dhcp21% bg } | [1] + continued sleep 100 | sleep 200 } | dhcp21% ps j29245; ps j29246 } | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND } | akr 29245 29244 29245 94d480 2 I p3 0:00.00 sleep 100 } | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND } | akr 29246 29244 29245 94d480 2 I p3 0:00.00 sleep 200 } } It's successfully resumed. OK, now, can you "fg" it, wait for the first sleep (but not the second) to exit, then ^Z again and check the PGIDs? If the PGID is going to change every time the group leader exits, then we've got a problem -- we can't simply record the group leader's PID and keep using it unless we arrange for a group leader that's guaranteed to stay alive for the whole pipeline. Another test to try: echo | sleep 100 | sleep 200 If you ^Z this, do both sleeps get the same PGID, or do they each become their own process group? (I'm hoping the latter, for sanity, otherwise it's a guessing game as to what PID becomes the leader.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 18:45 ` Bart Schaefer @ 2000-05-06 19:03 ` Tanaka Akira 0 siblings, 0 replies; 10+ messages in thread From: Tanaka Akira @ 2000-05-06 19:03 UTC (permalink / raw) To: zsh-workers In article <1000506184503.ZM6391@candle.brasslantern.com>, "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: > OK, now, can you "fg" it, wait for the first sleep (but not the second) > to exit, then ^Z again and check the PGIDs? | Z:akr@dhcp21% ktrace -i zsh -f | dhcp21% sleep 30|sleep 100 | ^Z | zsh: suspended sleep 30 | sleep 100 | dhcp21% jobs -l | [1] + 29347 suspended sleep 30 | | 29348 suspended sleep 100 | dhcp21% ps j | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29335 29333 29335 a0fe80 0 Is p0 0:00.11 /home/akr/.zsh/arch/i386-unknown-freebsd4.0/bin/zsh -l | akr 29346 29335 29346 a0fe80 1 S p0 0:00.07 zsh -f | akr 29347 29346 29347 a0fe80 2 T p0 0:00.00 sleep 30 | akr 29348 29346 29347 a0fe80 2 T p0 0:00.00 sleep 100 | akr 29349 29346 29349 a0fe80 1 R+ p0 0:00.00 ps j PGID of `sleep 100' is both 29347. No problem. | dhcp21% fg | [1] + continued sleep 30 | sleep 100 | ^Z | zsh: done sleep 30 | | zsh: suspended sleep 100 | dhcp21% ps j | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29335 29333 29335 a0fe80 0 Is p0 0:00.11 /home/akr/.zsh/arch/i386-unknown-freebsd4.0/bin/zsh -l | akr 29346 29335 29346 a0fe80 1 S p0 0:00.08 zsh -f | akr 29348 29346 29347 a0fe80 1 T p0 0:00.00 sleep 100 | akr 29365 29346 29365 a0fe80 1 R+ p0 0:00.00 ps j | akr 29352 29350 29352 9099c0 0 Ss+ p1 0:00.12 /home/akr/.zsh/arch/i386-unknown-freebsd4.0/bin/zsh -l | dhcp21% The PGID is not changed: 29347. > Another test to try: > > echo | sleep 100 | sleep 200 > > If you ^Z this, do both sleeps get the same PGID, or do they each become > their own process group? (I'm hoping the latter, for sanity, otherwise > it's a guessing game as to what PID becomes the leader.) Wow! This cannot stop with ^Z. | Z:akr@dhcp21% zsh -f | dhcp21% echo $$ | 29385 | dhcp21% tty | /dev/ttyp0 | dhcp21% echo | sleep 100 | sleep 200 | ^Z `ps j' from another termianl before ^Z: | Z:akr@dhcp21% ps j | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29335 29333 29335 a0fe80 0 Ss p0 0:00.12 /home/akr/.zsh/arch/i386 | akr 29385 29335 29385 a0fe80 1 S p0 0:00.03 zsh -f | akr 29388 29385 29388 a0fe80 1 S p0 0:00.00 sleep 100 | akr 29389 29385 29389 a0fe80 1 S+ p0 0:00.00 sleep 200 | akr 29352 29350 29352 9099c0 0 Ss p1 0:00.14 /home/akr/.zsh/arch/i386 | akr 29390 29352 29390 9099c0 1 R+ p1 0:00.00 ps j Hm. Two sleep commands has own PGID. They are both process group leader. `ps j' from another termianl after ^Z: | Z:akr@dhcp21% ps j | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 29335 29333 29335 a0fe80 0 Is p0 0:00.12 /home/akr/.zsh/arch/i386 | akr 29385 29335 29385 a0fe80 1 S p0 0:00.03 zsh -f | akr 29388 29385 29388 a0fe80 1 S p0 0:00.00 sleep 100 | akr 29389 29385 29389 a0fe80 1 T+ p0 0:00.00 sleep 200 | akr 29352 29350 29352 9099c0 0 Ss p1 0:00.14 /home/akr/.zsh/arch/i386 | akr 29391 29352 29391 9099c0 1 R+ p1 0:00.00 ps j Only `sleep 200' is stopped because foreground process group for ttyp0 is 29389. Maybe. -- Tanaka Akira ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 17:48 ` Tanaka Akira 2000-05-06 18:45 ` Bart Schaefer @ 2000-05-06 19:58 ` Tanaka Akira 2000-05-06 21:23 ` Bart Schaefer 1 sibling, 1 reply; 10+ messages in thread From: Tanaka Akira @ 2000-05-06 19:58 UTC (permalink / raw) To: zsh-workers In article <hvozoq3mux1.fsf@serein.m17n.org>, Tanaka Akira <akr@m17n.org> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 19:58 ` Tanaka Akira @ 2000-05-06 21:23 ` Bart Schaefer 2000-05-06 21:41 ` Tanaka Akira 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2000-05-06 21:23 UTC (permalink / raw) To: Tanaka Akira, zsh-workers On May 7, 4:58am, Tanaka Akira wrote: } Subject: Re: fg/bg on FreeBSD. } } In article <hvozoq3mux1.fsf@serein.m17n.org>, } Tanaka Akira <akr@m17n.org> 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. } [...] } } I confirmed following modification prevents the problem. But } definitely this is too radical... } } Index: Src/exec.c } =================================================================== } - 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) { What happens if you reverse the order of the test? if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 || killpg(jobtab[list_pipe_job].gleader, 0) == -1) { What I'm trying to discover is whether killpg() continues to fail after a process is successfully added to the group. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: fg/bg on FreeBSD. 2000-05-06 21:23 ` Bart Schaefer @ 2000-05-06 21:41 ` Tanaka Akira 0 siblings, 0 replies; 10+ messages in thread From: Tanaka Akira @ 2000-05-06 21:41 UTC (permalink / raw) To: zsh-workers In article <1000506212352.ZM8935@candle.brasslantern.com>, "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: > What happens if you reverse the order of the test? > > if (setpgrp(0L, jobtab[list_pipe_job].gleader) == -1 || > killpg(jobtab[list_pipe_job].gleader, 0) == -1) { Wow! It's good idea. | Z:akr@dhcp21% ktrace -i Src/zsh -f | dhcp21% echo|sleep 100 | ^Z | zsh: done echo | | zsh: suspended sleep 100 | dhcp21% jobs -l | [1] + 50065 done echo | | 50066 suspended sleep 100 | dhcp21% ps j50066 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 50066 50064 50065 97d1c0 1 T p0 0:00.00 sleep 100 | dhcp21% bg | [1] + done echo | | continued sleep 100 | dhcp21% ps j50066 | USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND | akr 50066 50064 50065 97d1c0 1 S p0 0:00.00 sleep 100 It's resumed successfully. | dhcp21% | [1] + done echo | sleep 100 | dhcp21% exit > What I'm trying to discover is whether killpg() continues to fail after > a process is successfully added to the group. | Z:akr@dhcp21% kdump|egrep 'kill|fork|exit|setpgid|wait' | 50064 zsh CALL fork | 50064 zsh RET fork 50065/0xc391 | 50065 zsh RET fork 0 | 50065 zsh CALL setpgid(0,0xc391) | 50065 zsh RET setpgid 0 | 50064 zsh CALL fork | 50064 zsh RET fork 50066/0xc392 | 50065 zsh CALL exit(0) Now, echo is zombie. | 50066 zsh RET fork 0 | 50066 zsh CALL setpgid(0,0xc391) | 50066 zsh RET setpgid 0 sleep comes into the group successfully. | 50066 zsh CALL kill(0xffff3c6f,0) | 50066 zsh RET kill 0 killpg succeeds. | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 50065/0xc391 | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 0 | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 50066/0xc392 echo is waited. | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 0 | 50064 zsh CALL fork | 50064 zsh RET fork 50067/0xc393 | 50067 zsh RET fork 0 | 50067 zsh CALL setpgid(0,0xc393) | 50067 zsh RET setpgid 0 | 50067 ps CALL exit(0) | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 50067/0xc393 | 50064 zsh CALL kill(0xfffe7960,0) | 50064 zsh RET kill -1 errno 3 No such process | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 0 | 50064 zsh CALL kill(0xffff3c6f,0x13) | 50064 zsh RET kill 0 | 50064 zsh CALL fork | 50064 zsh RET fork 50071/0xc397 | 50071 zsh RET fork 0 | 50071 zsh CALL setpgid(0,0xc397) | 50071 zsh RET setpgid 0 | 50071 ps CALL exit(0) | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 50071/0xc397 | 50064 zsh CALL kill(0xfffe7960,0) | 50064 zsh RET kill -1 errno 3 No such process | 50064 zsh CALL wait4(0xffffffff,0xbfbff530,0x3,0) | 50064 zsh RET wait4 0 | 50064 zsh CALL kill(0xffff3c6f,0xf) | 50064 zsh RET kill 0 | 50064 zsh CALL wait4(0xffffffff,0xbfbff5c0,0x3,0) | 50064 zsh RET wait4 50066/0xc392 | 50064 zsh CALL wait4(0xffffffff,0xbfbff5c0,0x3,0) | 50064 zsh RET wait4 -1 errno 10 No child processes | 50064 zsh CALL exit(0) -- Tanaka Akira ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2000-05-08 9:17 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-08 8:48 fg/bg on FreeBSD Sven Wischnowsky 2000-05-08 9:17 ` Tanaka Akira -- strict thread matches above, loose matches on Subject: below -- 2000-05-06 15:03 Tanaka Akira 2000-05-06 17:08 ` Bart Schaefer 2000-05-06 17:48 ` Tanaka Akira 2000-05-06 18:45 ` Bart Schaefer 2000-05-06 19:03 ` Tanaka Akira 2000-05-06 19:58 ` Tanaka Akira 2000-05-06 21:23 ` Bart Schaefer 2000-05-06 21:41 ` Tanaka Akira
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).