Re: mc sets process group differently from shell; forgets to close fd# 3

[Denis Vlasenko <vda linux googlemail com>]

On Friday 20 April 2007 23:00, Pavel Tsekov wrote:
> > Small one: child process is not given its own porcess group when run
> > under mc, while under sh it is. It means that if child will create its
> 
> Yes - because, you have a shell which supports job control.
> 
> > own process group by itself and then die, under shell it works but
> > under mc mc will auto-background itself on child's death,
> > because tty's pgrp will not match mc's. Nasty.
> 
> I am confused a bit by the statement above. The foreground process
> group (tty's pgrp) is controlled by the process which has the
> controlling terminal - the shell itself.

Parent and children aren't different here. They both
can manipulate ctty's pgrp.

Whenever you run a pipe from shell:

# sleep 1 | sleep 2

shell creates new process group. First process in pipe (sleep 1)
with pid=pid1 will become process group leader by executing
setpgrp(0, 0); 2nd, 3rd and so on processes (sleep 2 above)
will join this process group by doing
setpgrp(0, pid1), and all these child processes can switch tty
pgrp to pid1 by doing tcsetpgrp(ctty_fd, pid1).
(In theory just one child can do it, but because of possible races
all children do it, in parallel). This will make
parent shell process to become _backgrounded_ (because parent process
is *not* in pid1 process group, which is the foreground group now).

Note that this process group switch is done *by children*, not parent.
(However, parent can do it too for paranoid reasons, and parent definitely
will want to re-foreground itself when all children exit).

> Neither the child nor MC 
> can manipulate the foreground process group.

Yes it can. I spent entire day doing exactly this while I was fixing
a shell from busybox project. It works.

> Please, explain in 
> details what you mean. If can provides a simple testcase to reproduce
> the problem I'd be happy to investigate.

Simple: start bash from mc, and kill it so that it (bash) have no chance
to restore tty's pgrp:

# mc
# bash
bash-3.2# kill -KILL $$
[1]+  Stopped                 mc
# _

See? mc is backgrounded!

This is how it should work (and in fact works when parent is a shell, not mc):

# bash
bash-3.2# kill -KILL $$
Killed <=========== parent shell reports exit status of child
# _

Parent shell has recovered (did not end up backgrounded), because it brought
itself to foreground (did tcsetpgrp(ctty_fd, parent_pid)) after child exited.
--
vda