peachey (02/08/83)
(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