[net.unix-wizards] setpgrp

curt@sdcrdcf.UUCP (Curt Dodds) (09/27/85)

References:

I am using setpgrp() (in a shell that I am writing) to change the PROCESS
GROUP ID of the child after the first fork().  This allows me to use kill()
to send signals to that child and all of its children (because they
share the same PROCESS GROUP ID).

However, it seems that certain programs which try to open the device
"/dev/tty" don't work when setpgrp() has been called.  Examples are
"su" and a version of "mail" that I have.

A symptom: a "ps" shows the TTY of each child to be "?".
		   I can even type "ps -t\?" and get a list of these children.

Nowhere in the documentation is it indicated that setpgrp() should have
any effect on the controlling terminal for a process.

Why is this happening?

P.S.
By removing the call to setpgrp() this problem disappears completely.

adjg@neology.OZ (Andrew Gollan) (09/27/85)

I have found what I consider a long standing bug(?) in the implementation
of setpgrp(2) in standard system 3 and system 5 kernels.

If a process is the first to open a tty device and is a process group
leader its process group will become the controlling pgrp for that tty.
t_pgrp will be set to p_pgrp and u_ttyp will be set to &t_pgrp.  When
the process exits the following code cleans up t_pgrp.

	if
	(
	    (p->p_pid == p->p_pgrp)
	    &&
	    (u.u_ttyp != NULL)
	    &&
	    (*u.u_ttyp == p->p_pgrp)
	)
	{
		*u.u_ttyp = 0;
		signal(p->p_pgrp, SIGHUP);
	}


When setpgrp is called the following code only zeros the u_ttyp field
and leaves t_pgrp alone. Hence the terminal remains bound to a pgrp for
ever.

	if (p->p_pgrp != p->p_pid)
		u.u_ttyp = NULL;
	p->p_pgrp = p->p_pid;

I discovered this unpleasantness when writing a new init. I wrote a
program to start up shells, daemons and so forth providing them with
the console as as standard output and error. If the program was not
intended to run interactively on the console I called setpgrp to
dissociate it from the terminal. Nothing thereafter would become the
controlling pgrp of the console. getpass() failed to open /dev/tty when
login finally started, and so on and so forth.

			      Andrew Gollan

UUCP:	seismo!munnari!neology.oz!adjg		ACSnet:	adjg@neology.oz

			Neology Limited, Australia
-- 
			      Andrew Gollan

UUCP:	seismo!munnari!neology.oz!adjg		ACSnet:	adjg@neology.oz

			Neology Limited, Australia

alan@drivax.UUCP (Alan Fargusson) (09/29/85)

> I am using setpgrp() (in a shell that I am writing) to change the PROCESS
> GROUP ID of the child after the first fork().  This allows me to use kill()
> to send signals to that child and all of its children (because they
> share the same PROCESS GROUP ID).
> 
> However, it seems that certain programs which try to open the device
> "/dev/tty" don't work when setpgrp() has been called.  Examples are
> "su" and a version of "mail" that I have.
> 
> A symptom: a "ps" shows the TTY of each child to be "?".
> 		   I can even type "ps -t\?" and get a list of these children.
> 
> Nowhere in the documentation is it indicated that setpgrp() should have
> any effect on the controlling terminal for a process.
> 
> Why is this happening?
> 
> P.S.
> By removing the call to setpgrp() this problem disappears completely.

I know that the documetation is not clear on this, but the kernel uses
the process group to determine the controlling terminal. The result of
this is that changing the process group effectivly disconnects the process
from the controlling terminal. Some utilities like lpsched use setpgrp()
to prevent the terminal from sending them signals because they use signals
to decide when there is work to do.
-- 

Alan Fargusson.

{ ihnp4, amdahl, mot }!drivax!alan

sean@ukma.UUCP (Sean Casey) (09/29/85)

In article <2366@sdcrdcf.UUCP> curt@sdcrdcf.UUCP (Curt Dodds) writes:
>
>I am using setpgrp() (in a shell that I am writing) to change the PROCESS
>GROUP ID of the child after the first fork().  This allows me to use kill()
>to send signals to that child and all of its children (because they
>share the same PROCESS GROUP ID).
>
>However, it seems that certain programs which try to open the device
>"/dev/tty" don't work when setpgrp() has been called.  Examples are
>"su" and a version of "mail" that I have.

Hey!  Are you on System V?  Maybe this has something to do with the problem
of /dev/tty sometimes not being openable from the console.


-- 

-  Sean Casey                           UUCP:   sean@ukma.UUCP   or
-  Department of Mathematics                    {cbosgd,anlams,hasmed}!ukma!sean
-  University of Kentucky               ARPA:   ukma!sean@ANL-MCS.ARPA