httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: New graceful restart mechanism.
Date Mon, 04 Jun 2001 18:34:50 GMT

> > > >                                    This could be improved a bit, by using
> > > > OOB data to wake up the thread, and we would only check the pod if we
> > > > received OOB data.  This is an optimization however, and I am not sure
how
> > > > that would work in real-life.
> > >
> > > Err, I'm not sure either :)  On which connection would you send OOB
> > > data?  How would we detect that there was OOB data?  If select(),  I
> > > thought we were removing the need for select() (think
> > > "SINGLE_LISTEN_UNSERIALIZED_ACCEPT")...   If SIGURG, I thought we were
> > > avoiding signal-based processing (not sure of SIGURG portability
> > > anyway)...  I guess I'm missing something real basic here...
> >
> > I was thinking of doing the connect, and actually sending OOB data over
> > the wire.  I seem to recall some way to determine when OOB data was read
> > from the network, but I can't find it right now.
>
> You can have SIGURG sent when OOB data is received.  You can do
> select()/poll() to see if OOB data has been received.  You can call
> recv() or recvmsg() or recvfrom() asking for MSG_OOB.  I dunno what
> else there is.

I was really hoping I saw something during the accept phase, but looking
through it, you are correct, what I was remembering was select/poll.  :-(

> > > a) weird firewall-like rules on some possibly-weird systems may keep
> > >    the connect() from working; admin needs to be aware
> >
> > We are connecting from localhost to localhost.  While weird firewall rules
> > may stop this, remember that we are connecting on a port that should be
> > accessible, because it is meant to accept connections.  :-)
>
> The rules of firewall-like constructs often distinguish between
> accepting connections vs. requesting new connections.  They can also
> be user id or group-specific ("nobody").
>
> This is just something to be aware of when people have shutdown
> problems.  The traces after connect() fails will be helpful.

Good point.  Something to document and just be aware of.

> > > b) TCP/IP may be dead/dying and socket()+connect() won't work
> > >
> > >    I'm not sure how to kill apache on OS/390 when the stack goes away.
> > >
> > >    I was told previously by you and possibly others that I couldn't
> > >    teach the child process to tell the parent to get the @#$% out
> > >    because the stack is dead.  If the stack is dead, the user can tell
> > >    apache to go away but nothing will happen and the child processes
> > >    will (probably) continue looping and getting weird errors on
> > >    select() or accept().
> > >
> > >    This needs to be solved.  For me, simply recognizing the magic
> > >    error feedback and using the magic error status (CHILD_EXITFATAL?)
> > >    is sufficient.
> >
> > Greg Ames stated quite emphatically, that if the stack dies on a 390
> > machine, the child process will wake up from select.  Once that happens,
> > the process will die, if for no other reason than that Apache dies when
> > select returns an error other than EINTR.
>
> We're in select()/poll() on OS/390 only if there is more than one
> listening socket. In general I would expect to be in accept().

Looking at the accept code, assuming accept returns ENETDOWN, we will die
correctly in this case.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message