httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Fear <>
Subject Re: feature idea
Date Sat, 08 Jun 1996 23:26:21 GMT
I'm new and naive about how apache really works, but I'll take a crack
at designing this anyway, as a good learning exercise :-)  Feedback
is certainly appreciated.

(And, if the idea is good, I'm even willing to code it.)

Brian Behlendorf writes:
> with log rotation currently, if you want to have the server wake up and 
> start logging somewhere else, you send it a HUP - but this also has the 
> effect of killing whatever transfers are in progress.  For most sites 
> this is noise since it happens late at night; but for some involved in 
> large-file downloads (we're setting up a site with 10 megabyte TIFFs for 
> example) this is something of a "bug".  Any ideas on how to ameliorate 
> this?  

The basic design is to let the main process tell the children to die
at a 'nice' time, so they get restarted by main with new config values.
The easiest way to do this appears (to me) to add a flag to short_score.
The main server sets the flag on receipt of a signal.  The child process
checks it when returning from the select call.  If the flag is set,
than the child just dies.  This leaves open current connections.

This shouldn't require write locking the scoreboard, becuase only the
main server process should write into this field.

This could be the default behavior of SIGHUP, particularly with the
addition of /status/.   /status/ could be used by an admin to get the
pid of a hung child process so that it can be killed directly instead
of using SIGHUP.

It avoids adding configuration cycling directly to apache, because
cron can be used to restart configurations.  I'm an old-enough unix
hand that I really try to avoid writing things that are already written.
If y'all really want to check for config file changes, I'd do it using
a signal from cron instead of having to rewrite the timing code.
Perhaps the main process would store a signature (mtime and/or size)
for each file and only re-read it if the signature has changed.  Then
we could add instructions to the doc for setting-up cron to do this.

That's just my opinion.  Of course, I could be wrong :-)
Howard Fear      email1:

View raw message