httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: New graceful restart mechanism.
Date Mon, 04 Jun 2001 18:15:24 GMT
<> writes:

> > >                                    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
> > 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.

> > ---------/----------
> >
> > This feels like a reasonable the way to go but when this has been
> > brought up before I've had some general worries about it that perhaps
> > folks can dispel.  (Maybe I'm just mad because when I got the great
> > idea to use connect() it wouldn't do what I wanted it to do :) )
> >
> > I remain at least a little concerned about using connect() because
> >
> > 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.

> > 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().

Jeff Trawick | | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message