>
> > 2. This is the nasty part... Due to a bug in the Windows part of Apache, child
>processes are
> > inheriting open socket descriptors. When the Apache child process segfaults, its
>child processes
> > have copies of the open socket descriptors which can prevent the new Apache
>process from
accepting
> > connections.. This could explain some long standing bug reports in the bugdb.
>
> Why, specifically, do we have the parent keep the sockets open? Can we simply open
>the parent
socket
> (to test that it is available, and try it exclusively, since we don't do that
>correctly now
anyways),
> then close it, and let the child threads open their own (non-inhertable) sockets,
>themselves?
> Does this really cost us that much?
>
The problem is that the processes started by the child are inheriting the sockets from
the child. I
wasn't clear about that.
The parent needs to manage the listen sockets to enable graceful restarts to work.
Having the
parent own the listeners allows us to not destroy the listen queue (and anything on
it) across a
graceful restart. The code to prevent inheriting the socket is quite simple, it was
just behaving
strangely (see below).
> > Solutions...
> > Sockets are created as inheritable by default. We need to use DuplicateHandle to
>create
> > noninheritable handles of the listeners. This is a bit tricker than it first
>appears and I
spent
> > the better part of this AM getting this to work. There are some funky race
>conditions between
> > CreateProcess() (to create the Apache child process) and WSADuplicateSocket() that
>will, if not
> > handled properly, undo any effort to make the listeners noninheritable.
>
> Not sure how there is a race here... they are still opened (in the parent)
>inheritable), simply
dup as
> a non-inheritable and close the inherited socket in the child, no?
Heh, the behaviour is quite nonintuitive. I set the listeners noninheritable in the
parent process.
Then call CreateProcess. If the created process initializes -after- the call to
WSADuplicateSocket
in the parent process, the sockets are inherited anyway. This looks like a bug in the
Windows API.
If I ensure the child is fully initialized before calling WSADuplicateSocket (by
inserting a Sleep
or WaitForInputIdle after the call to CreateProcess), the sockets are not inherited.
>
> > I have no thoughts on how to cleanly solve problem 1. Would be nice if there were
>some system
calls
> > to bind the two processes together in a parent/child relationship.
>
> Oh, yeah... took them till NT 5 to figure that out themselves :-/
Not even sure NT 5 fixes it right. Nothing I've read about the process group support
implied that a
segfaulting parent would take out a child. Hope to commit the code to handle the
socket inheritance
tomorrow (having trouble with getting WaitForInputIdle to link. The prototype is not
being picked up
out of winuser.h).
Bill
