Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: trawick@bellsouth.net
To: new-httpd@apache.org
Subject: Re: New graceful restart mechanism.
References: <Pine.LNX.4.30.0106041028190.28041-100000@koj.rkbloom.net>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 04 Jun 2001 14:15:24 -0400
In-Reply-To: <Pine.LNX.4.30.0106041028190.28041-100000@koj.rkbloom.net>
Message-ID: <m3vgmcru0z.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 73
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

<rbb@covalent.net> 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
> > "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.

> > ---------/----------
> >
> > 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 | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...