Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ateng!chip From: chip@ateng.com (Chip Salzenberg) Newsgroups: comp.bugs.sys5 Subject: Re: SysVR3.2 Setpgrp behaviour Message-ID: <253B77E4.16917@ateng.com> Date: 17 Oct 89 19:05:06 GMT References: <1970@oid.UUCP> <1273@virtech.UUCP> <253664A4.20995@ateng.com> <10199@xanth.cs.odu.edu> Organization: A T Engineering, Tampa, FL Lines: 32 According to kremer@cs.odu.edu (Lloyd Kremer): >According to chip@ateng.com (Chip Salzenberg): >>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. > >Do you need two forks? Wouldn't the "second" fork alone be sufficient? Unfortunately, the first fork() is required to ensure that setpgrp() will work correctly. You see, setpgrp() has two functions: 1. Make the process a process group leader. 2. Make the process have no controlling tty. Here's the ugly part: If function #1 isn't needed -- i.e. if the process is already a process group leader -- then function #2 is _not_ performed. In other words, if a process is a process group leader, setpgrp() does nothing. (Sigh.) So summarize: The fork() _before_ the setpgrp() guarantees that the child isn't a process group leader, and thus ensures that setpgrp() will work, losing the controlling tty. The fork() _after_ the setpgrp() guarantees that the grandchild won't ever get a controlling tty by accident. Now you see why I said that setpgrp() is a grody hack. :-( -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; or "'Why do we post to Usenet?' Naturally, the answer is, 'To get a response.'" -- Brad "Flame Me" Templeton