httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: nasty bug in Apache for Windows (1.3 & 2.)
Date Fri, 13 Jul 2001 02:40:25 GMT
> > 2. This is the nasty part... Due to a bug in the Windows part of Apache, child processes
> > 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
> > 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
> (to test that it is available, and try it exclusively, since we don't do that correctly
> 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
parent own the listeners allows us to not destroy the listen queue (and anything on it) across
graceful restart.  The code to prevent inheriting the socket is quite simple, it was just
strangely (see below).

> > Solutions...
> > Sockets are created as inheritable by default. We need to use DuplicateHandle to
> > noninheritable handles of the listeners.  This is a bit tricker than it first appears
and I
> > the better part of this AM getting this to work. There are some funky race conditions
> > 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),
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
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
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
> > 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).


View raw message