Subject: Re: fork/vfork and file descriptors problems
To: Kim Ludwig <ludwig@grc.nasa.gov>
From: David Brownlee <abs@netbsd.org>
List: netbsd-help
Date: 02/15/2000 17:14:31
	Set the close-on-exec flag on the descriptors and use fork().
	See fcntl().


		David/absolute

On Tue, 15 Feb 2000, Kim Ludwig wrote:

> First of all, I am using NetBSD 1.3.3 and gcc 2.7.2.2+myc2
> 
> While inside one running program (call it A), I want to create another,
> totally independent, process (call it B), such that process A could exit or
> be killed and restarted without affecting B in any way.
> 
> One way I understand to do this is to have A call fork(). Then, the child
> process, B, should call execv() to execute the desired program.
> 
> One complication is that process A has several listening sockets as well as
> a couple other socket connections open at the time it wants to create B. I
> understand that, upon fork(), process B inherits *copies* of all those open
> descriptors, and so before proceeding with the execv() call, I should first
> close() all those open descriptors in process B.
> 
> BUT, when I do it this way, all of process A's descriptors seem to get
> closed too, and A can no longer communicate on its sockets. Bad.
> 
> On the other hand, if I do NOT close all the descriptors in B, then if A
> exits and is restarted while B is still alive, then A generates BIND
> FAILED--ADDRESS ALREADY IN USE errors when it tries to open its sockets.
> 
>  Other things I have tried:
> 
> - Using vfork() instead of fork(), but not closing any descriptors. Seems
> to have the same BIND FAILED problem.
> 
> - Making B into a daemon by calling fork() twice, each time having the
> parent exit. (This comes from  "Unix Network Programming, Vol 1" by W.
> Richard Stevens.) Even after all this, B still seems to have a hold on A's
> descriptors.
> 
> What am I missing here? Please help.
> 
> Thanks.
>