You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Colm MacCarthaigh <co...@stdlib.net> on 2005/08/25 12:01:14 UTC
Graceful stop implementation nits
Now that the ap_close_listeners() code is committed, implementing a
graceful stop is relatively trivial, I already have it working here for
me. However there are some complicated nits which I thought I'd solicit
feedback on.
One of the main benefits of a graceful stop is to allow for upgrading
httpd without kicking off long downloads. For this situation, it's
desirable that it be possible to do;
make install
apachectl graceful-stop
apachectl start
and have it work as the admin would expect, but this leads to some
complications. Files like the ScriptSock, ScoreBoardFile,
SSLSessionCache, LockFile, LDAPSharedCacheFile and so on will get
clobbered. Ther will be two instances of httpd, pointing at the same
files.
To solve this, I'd like allow the administrator do something like;
ScoreBoardFile /var/run/apache_status-%p
ScriptSock cgi_sock.%p
SSLSessionCache shm:/path/to/datafile.%p
where %p is the PID of the server. Or even better I'd like to be able to
do;
# Create a directory for server-related state, gets
# removed on server exit.
StateDirectory %p.state/
ScoreBoardFile $statedir/apache_status
ScriptSock $statedir/cgi_sock
SSLSessionCache shm:$statedir/datafile
But either way, it starts to look like an embedded macro engine, and
it's not at all clear to admin that they can't use those expansions
elsewhere. This is a mean problem.
What's really needed is a lightweight embedded scripting engine for
config parsing, but that's a lot of overkill for simply making graceful
stops working.
Has anyone got any comments on any other approaches? or on the
suitability of adding a small ammount of expansion to the state-related
directives above?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Graceful stop implementation nits
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 25, 2005, at 6:01 AM, Colm MacCarthaigh wrote:
>
> Now that the ap_close_listeners() code is committed, implementing a
> graceful stop is relatively trivial, I already have it working here
> for
> me. However there are some complicated nits which I thought I'd
> solicit
> feedback on.
>
> One of the main benefits of a graceful stop is to allow for upgrading
> httpd without kicking off long downloads. For this situation, it's
> desirable that it be possible to do;
>
> make install
> apachectl graceful-stop
> apachectl start
>
> and have it work as the admin would expect, but this leads to some
> complications. Files like the ScriptSock, ScoreBoardFile,
> SSLSessionCache, LockFile, LDAPSharedCacheFile and so on will get
> clobbered. Ther will be two instances of httpd, pointing at the same
> files.
>
> To solve this, I'd like allow the administrator do something like;
>
> ScoreBoardFile /var/run/apache_status-%p
> ScriptSock cgi_sock.%p
> SSLSessionCache shm:/path/to/datafile.%p
>
> where %p is the PID of the server. Or even better I'd like to be
> able to
> do;
>
> # Create a directory for server-related state, gets
> # removed on server exit.
> StateDirectory %p.state/
>
> ScoreBoardFile $statedir/apache_status
> ScriptSock $statedir/cgi_sock
> SSLSessionCache shm:$statedir/datafile
>
> But either way, it starts to look like an embedded macro engine, and
> it's not at all clear to admin that they can't use those expansions
> elsewhere. This is a mean problem.
>
> What's really needed is a lightweight embedded scripting engine for
> config parsing, but that's a lot of overkill for simply making
> graceful
> stops working.
>
> Has anyone got any comments on any other approaches? or on the
> suitability of adding a small ammount of expansion to the state-
> related
> directives above?
>
Although StateDirectory is nice, I think it would
complicate things. Instead, the '%p' idea is cleaner;
Of course, it's been proposed before that all server-specific
files and resources that are clobberable are internally
prepended-appended with PID, as we already do with some. That,
I think, would be the best solution.
Re: Graceful stop implementation nits
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Aug 25, 2005 at 11:17:29AM +0100, Joe Orton wrote:
> > apachectl graceful-stop
> > apachectl start
> >
> > and have it work as the admin would expect, but this leads to some
> > complications. Files like the ScriptSock, ScoreBoardFile,
> > SSLSessionCache, LockFile, LDAPSharedCacheFile and so on will get
> > clobbered. Ther will be two instances of httpd, pointing at the same
> > files.
>
> I think the right way to fix this is to make the default behaviour DTRT
> without requiring fancy configuration hacks.
>
> - all shmem stuff should be using anonymous shm segments by default on
> the trunk; so the scoreboard and SSL/LDAP caches should all be fine; do
> you still see issues there really?
Not for me on Linux, but I'm trying to think out the scenarious where
the filename will matter. From looking at apr, there seem to be some
cases when neither anon shm or mmap("/dev/zero") is available, or is
that near-impossible?
I guess just documenting this loudly in stopping.xml is an approach?
> - lock files created in the parent should append the parent pid to the
> filename automatically, LockFile already does in prefork at least. It
> should be done for ScriptSock too, I think that's been suggested before
> once already.
O.k. that sounds good, LockFile, ScriptSock, and SSLMutex
fcntl|flock|file all need a pid appendage, anyone know am I missing any?
Also, DavLockDB needs be the same for multiple instances right? And
sdbm should work it out.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Graceful stop implementation nits
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Aug 25, 2005 at 11:01:14AM +0100, Colm MacCarthaigh wrote:
> Now that the ap_close_listeners() code is committed, implementing a
> graceful stop is relatively trivial, I already have it working here for
> me. However there are some complicated nits which I thought I'd solicit
> feedback on.
>
> One of the main benefits of a graceful stop is to allow for upgrading
> httpd without kicking off long downloads. For this situation, it's
> desirable that it be possible to do;
>
> make install
[fixing "make install" to avoid overwriting already-mapped DSOs here
would probably useful at some point!]
> apachectl graceful-stop
> apachectl start
>
> and have it work as the admin would expect, but this leads to some
> complications. Files like the ScriptSock, ScoreBoardFile,
> SSLSessionCache, LockFile, LDAPSharedCacheFile and so on will get
> clobbered. Ther will be two instances of httpd, pointing at the same
> files.
I think the right way to fix this is to make the default behaviour DTRT
without requiring fancy configuration hacks.
- all shmem stuff should be using anonymous shm segments by default on
the trunk; so the scoreboard and SSL/LDAP caches should all be fine; do
you still see issues there really?
- lock files created in the parent should append the parent pid to the
filename automatically, LockFile already does in prefork at least. It
should be done for ScriptSock too, I think that's been suggested before
once already.
joe
Re: Graceful stop implementation nits
Posted by Andrew Stribblehill <a....@durham.ac.uk>.
Quoting Colm MacCarthaigh <co...@stdlib.net> (2005-08-25 11:01:14 BST):
>
> Has anyone got any comments on any other approaches? or on the
> suitability of adding a small ammount of expansion to the state-related
> directives above?
I've always felt it was a shame that you could do -DFOO but not
-DFOO=bar. If it were allowed, it would be a simple matter to allow
definitions to be instantiated from within the config file.
--
SOLE LUNDY FASTNET
WEST OR NORTHWEST 5 TO 7, BACKING SOUTHWEST 4 OR 5, INCREASING 6 IN
WEST SOLE LATER. SHOWERS, RAIN IN SOLE LATER. MAINLY GOOD