System III SETPGRP bug
utzoo!decvax!harpo!utah-cs!sask!hssg40!peachey
utzoo!decvax!harpo!utah-cs!sask!hssg40!peachey
Tue Feb 8 14:14:46 AEST 1983
(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
More information about the Net.bugs.usg
mailing list