Re: fg/bg on FreeBSD.

Re: fg/bg on FreeBSD.

[Sven Wischnowsky]

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

Re: fg/bg on FreeBSD.

[Tanaka Akira]

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

Re: fg/bg on FreeBSD.

[Tanaka Akira]

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

Re: fg/bg on FreeBSD.

[Bart Schaefer]

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

Re: fg/bg on FreeBSD.

[Tanaka Akira]

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

Re: fg/bg on FreeBSD.

[Tanaka Akira]

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

Re: fg/bg on FreeBSD.

[Bart Schaefer]

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

Re: fg/bg on FreeBSD.

[Tanaka Akira]

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

Re: fg/bg on FreeBSD.

[Bart Schaefer]

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

fg/bg on FreeBSD.

[Tanaka Akira]

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