On Mon, Jan 07, 2002 at 11:51:10PM -0800, Jos Backus wrote: > On Mon, Jan 07, 2002 at 11:27:53PM -0800, Aaron Bannert wrote: > > I think we should take the fork() stuff out of apr_proc_detach() > > instead. Detach is doing what it's supposed to, creating a new session > > (and therefore detaching from the controlling terminal). The only way > > it can reliably do that is if it is not a pgrp leader. IMO the way > > to handle this is to let apr_proc_deatch() assume it is already a > > non pgrp leader and put the fork() calls that ensure this outside. > > What about the reopening of fd 0-2 that also happens inside apr_proc_detach()? > We probably don't want that to happen with NO_DETACH (my latest patch fixes > this).
Why not? We redirect to /dev/null and then later reopen stderr to the log file (and possible stdout to other places, I don't know). Seems reasonable to me when detaching or not. > > Another option is to have apr_proc_deatch() simply check if it is > > the pgrp leader, and if so to only then call the fork. > > Wouldn't we need to create a new apr_ function to perform this check because > it calls the platform-specific getpgrp()/... functions? Not necessarily, since this is a native unix implementation -- we just have to make sure that getpgid exists on that particular unix. > I'm assuming that the > pgrp leader check simply involves checking if getpgrp() == getpid(). Correct? Yes, that's how I understand it. -aaron
