Message-ID: <34ACC7B8.130C46F1@algroup.co.uk>
Date: Fri, 02 Jan 1998 10:55:52 +0000
From: Ben Laurie <ben@algroup.co.uk>
Organization: A.L. Digital Ltd.
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: latest redhat rpm of apache
References: <Pine.LNX.3.95dg3.980101125935.15212E-100000@twinlark.arctic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Dean Gaudet wrote:
> 
> Actually when I mailed ewt@redhat.com about the kill -9 problem he
> asked me if there was any way for him to know the daemon had died.
> I said there wasn't and was there another daemon that behaved in a way he
> liked 'cause I could emulate it.  He said nope, it's a general problem,
> a solution would be great.  So here's my proposed solution.
> 
> After setting up the pid file the parent acquires a sharable lock on it.
> (The parent exits if the lock fails).  Each child also child acquires
> a sharable lock.  flock() or fcntl() will work for this.
> 
> A support utility "waitlock filename timeout" attempts to acquire an
> exclusive lock on filename.  Once it has acquired the exclusive lock
> it exits with code 0.  On any error it exits with code 1, on timeout it
> exits with code 2.

Hang on - how is it going to ever acquire an exclusive lock? The parent
is still holding a shared lock! I presume you have a model along the
lines of:

1. Launch children
2. Acquire shared lock
3. Wait for signal
4. Release shared lock
5. Go to 1

(1&2 can be swapped, of course). But even this model relies on semantics
that I'm not convinced are defined, i.e. that the exclusive lock will be
acquired as soon as it can be.

> Then shutting down the server becomes:
> 
>     kill -TERM `cat /var/run/httpd.pid`
>     waitlock /var/run/httpd.pid 600
>     exit $?
> 
> I suppose you could do kill -9, but I kinda hate doing that even in
> completely broken situations, especially in scripts.  "killall -9 httpd"
> could take out completely unrelated httpds.
> 
> There's another use for this type of locking:  kill -USR1.  If you modify
> the children to all share lock the log files, then doing a waitlock
> after a rotation attempt will let you continue when all the children
> have completed.  But this still isn't as nice in my opinion as using a
> piped logger, because the piped logger can rotate immediately.

And I don't see how this can work at all - the children will overlap, so
the locked file will never be lockless (in general).

> But I think this is a nice way to know a signal has been received and
> processed.  An alternative is to use a control interface somewhat like
> INN does -- via a unix domain socket.

Or put the generation number in a file. Increment it when all the
children have died. Poll it in your kill script.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache