SysVR3.2 Setpgrp behaviour

[Chip Salzenberg]

According to cpcahil at virtech.UUCP (Conor P. Cahill):
>The setpgrp() program only places the current program into a different
>process group and disconnects the link from the process to the controlling
>tty.

Quite.

>PS-> you should still do a setpgrp() after the fork to ensure that your 
>new program does not recieve signals from the terminal.

You should also do another fork() AFTER the setpgrp().  Otherwise, the child
process remains a process group leader.  And if a process group leader
without a controlling tty opens a tty that no other process has open at the
time [inhale], then that tty becomes the process's controlling tty.  So the
child must fork() again; then the grandchild process is a safe daemon.

Finally:

	/*
	 * Daemon code.
	 * Insert error checking to taste.
	 */

	if (fork() != 0)
		exit(0);
	setpgrp();
	if (fork() != 0)
		exit(0);

	/*
	 * And away we go...
	 */

Personally, I think this whole "setpgrp does two jobs" is a grody hack.
It's as bad as the "setuid(getuid()) is reversible for all setuid programs
except setuid-root programs" grody hack.  Well, maybe not that bad.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip at ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton