🚀 go-pugleaf

	(Hopefully, the following bug report was not posted before
	we joined USENET in September, 1983.  If it was, I apologize
	for wasting your time!)

	In System III, the "setpgrp" system call allows a process
	to make itself a "process group leader", by setting p_pgrp
	to its process id.  At the same time, the pointer (u.u_ttyp)
	to the controlling terminal tty structure is cleared, to
	indicate that the process is no longer part of the process
	group that receives SIGHUP, SIGINT, and SIGQUIT from the
	terminal.

	Unfortunately, setpgrp doesn't check whether the calling
	process is already a group leader (p_pid == p_pgrp).
	If the leader of the process group associated with the
	terminal does a setpgrp, and then exits, the terminal
	doesn't "forget about" the process group (u.u_ttyp->t_pgrp
	doesn't get cleared), because u.u_ttyp has already
	been cleared by setpgrp.

	If some friendly person writes a little program that simply
	makes a setpgrp call, then overlays it on his login shell
	using the "exec" keyword (Bourne shell), he will leave
	the terminal in the erroneous state described above.  This
	means that anyone logging in on that terminal will be unable
	to signal his processes with SIGINT and SIGQUIT, until
	the system is rebooted.

	The best solution seems to be the addition of a check in
	setpgrp (sys4.c) so that setpgrp has no effect if the
	calling process is the group leader.

	The alternative solution is to make the terminal forget
	about the process group when the process group leader
	does setpgrp.  This approach seems less desirable, because
	it affects child processes which may already have been
	forked a long time before.

				Darwyn Peachey
				Hospital Systems Study Group

				harpo!utah-cs!sask!hssg40!peachey