You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Victor J. Orlikowski" <v....@gte.net> on 2001/04/11 22:24:08 UTC
Config files, main loop, and logging
Hi all,
Running into a problem, in the debugging of one of my favorite things,
mod_so. While doing some debugging, I had set LogLevel in my conf file
to debug, but got no messages about loading DSOs. So I dug a little
deeper...
Basically, in the main loop we do an ap_read_config(), which does an
init_server_config(). This, among other things, sets the server
loglevel to DEFAULT_LOGLEVEL, which is equivalent to APLOG_WARN.
Afterwards, we do ap_build_config(), which works on the directives for
mod_so and other modules.
Now, if a DSO is loaded successfully, mod_so tries to log this at the
APLOG_DEBUG level. It does so by calling ap_log_perror(), though it
really should do it by calling ap_log_error(). No matter. Under the
covers, those two both call log_error_core(). Now, the server loglevel
has not been changed from DEFAULT_LOGLEVEL, and so, the following
checks cause the debug messages from mod_so (and any other modules
that do debug logging as the initialize from directive) to never
happen:
if (s == NULL) {
/*
* If we are doing stderr logging (startup), don't log messages that are
* above the default server log level unless it is a startup/shutdown
* notice
*/
if ((level_and_mask != APLOG_NOTICE) &&
(level_and_mask > DEFAULT_LOGLEVEL))
return;
logf = stderr_log;
}
else if (s->error_log) {
/*
* If we are doing normal logging, don't log messages that are
* above the server log level unless it is a startup/shutdown notice
*/
if ((level_and_mask != APLOG_NOTICE) &&
(level_and_mask > s->loglevel))
return;
logf = s->error_log;
}
We see that, using ap_log_perror() (which sets s to NULL), any
messages that are logged at a lesser severity than APLOG_WARN are
discarded. With ap_log_error(), the server loglevel determines the
severity of message permitted - unfortunately, this isn't set to the
value specified in the conf file until ap_process_config_tree() is
called, 2 lines after ap_read_config() in main(). Hence, any debug
messages from modules like mod_so are discarded.
In my opinion, the correct way to fix this is to have the server
fields filled in, prior to acting upon module config options.
However, I'd like to kill two birds with one stone, and get rid of the
config re-read that occurs in main(). Which leads me to ask what
brought the necessity to load the config file a second time (i.e. why
is there a need to wait for the log files to "settle").
Congrats if you got this far,
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Config files, main loop, and logging
Posted by "Victor J. Orlikowski" <v....@gte.net>.
> The easiest way to accomplish step 4, is to assign a simple weight to
> directives. 99.9% of all directives will be assigned a weight of 0, the
> default. The remaining 0.1% will have a weight of 1 or higher. When a
> directive with a higher weight is encountered, it gets stored at the front
> of that line of the config tree in descending order, based on weight.
Yes, yes, a thousand times, yes!
(I thought this is what I meant by classes (or groups) of
directives. Perhaps I should have used a less OO-loaded term :)
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Config files, main loop, and logging
Posted by rb...@covalent.net.
On Thu, 12 Apr 2001, Victor J. Orlikowski wrote:
> > This is most definitely over-engineering. Just do two walks of the tree.
> > The first sets up all the internal structures, the second actually sets up
> > the server to run. Bam, problems solved. We don't need to provide full
> > debug logs the first time through, because we do a full debug log the
> > second time through, and it is the exact same steps.
>
> But, since mod_so is being processed as EXEC_ON_READ...it gets taken
> care of immediately on the first pass, Ryan. It loads the specified
> DSOs, so that their config directives can be handled, and in the
> second pass, we never do the needed logging for mod_so. We simply lose
> the messages, not log them in the second pass. And we can't very well
> make mod_so Not be EXEC_ON_READ, or else we need a *third* pass to
> enable mod_so on the second pass, and then take care of the directives
> for the DSOs on the third.
>
> I'm fairly convinced that some form of ordering needs to be imposed on
> how the directives are handled as the tree gets walked, if we don't
> want to lose messages from anything that logs prior to LogLevel being
> set.
Ahhhh..... I see the problem, and the reason this used to work.
Basically, we don't store EXEC_ON_READ directives in the tree. If we
did, this wouldn't be an issue at all. So, what's happening:
1) We read the file, and load the DSO's
2) We walk the tree once
3) We unload the DSO's
4) We re-read the file and load the DSO's
5) we walk the tree again.
What should happen:
1) We read the file, and load the DSO's, storing the DSO lines in the
tree
2) We walk the tree once
3) We unload the DSO's
4) We walk the tree again, reloading the DSO's as we hit them.
The easiest way to accomplish step 4, is to assign a simple weight to
directives. 99.9% of all directives will be assigned a weight of 0, the
default. The remaining 0.1% will have a weight of 1 or higher. When a
directive with a higher weight is encountered, it gets stored at the front
of that line of the config tree in descending order, based on weight.
This should accomplish everything that we require.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Config files, main loop, and logging
Posted by "Victor J. Orlikowski" <v....@gte.net>.
> This is most definitely over-engineering. Just do two walks of the tree.
> The first sets up all the internal structures, the second actually sets up
> the server to run. Bam, problems solved. We don't need to provide full
> debug logs the first time through, because we do a full debug log the
> second time through, and it is the exact same steps.
But, since mod_so is being processed as EXEC_ON_READ...it gets taken
care of immediately on the first pass, Ryan. It loads the specified
DSOs, so that their config directives can be handled, and in the
second pass, we never do the needed logging for mod_so. We simply lose
the messages, not log them in the second pass. And we can't very well
make mod_so Not be EXEC_ON_READ, or else we need a *third* pass to
enable mod_so on the second pass, and then take care of the directives
for the DSOs on the third.
I'm fairly convinced that some form of ordering needs to be imposed on
how the directives are handled as the tree gets walked, if we don't
want to lose messages from anything that logs prior to LogLevel being
set.
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Config files, main loop, and logging
Posted by rb...@covalent.net.
> <snip>
> > No, the intent of EXEC_ON_READ, is to allow modules to have an immediate
> > impact on how the config file is read. This is why all of the container
> > directives are EXEC_ON_READ. I am not saying that LogLevel fits into that
> > category, but lets be accurate about the goal of EXEC_ON_READ.
>
> > We are likely to always require two passes through the tree. The first
> > sets everything up, and the second actually starts the server. I see no
> > good way around that.
>
> *Sigh*
> EXEC_ON_READ is fine and dandy, but we have a problem.
> Namely, what is almost needed is to read in the tree, in its entirety,
> without performing any sort of walk initially.
>
> Then, we need some form of dependency heirarchy for directives, or at
> least a set of classes defining an order for their handling as the
> tree is walked for the first time.
>
> (Hrm. Sounds like a tree in which depth of nodes correlates to order
> of load....)
>
> For example, if an admin is debugging mod_so, and wants to have the
> logging set up to debug from the very start, we shouldn't hamstring
> him; least astonishment says it should just work. Meaning, LogLevel is
> among the first directives handled, so that the desired messages come
> through.
>
> Or maybe this is over-engineering...
This is most definately over-engineering. Just do two walks of the tree.
The first sets up all the internal structures, the second actually sets up
the server to run. Bam, problems solved. We don't need to provide full
debug logs the first time through, because we do a full debug log the
second time through, and it is the exact same steps.
Ryan
>
> However, Ryan is certainly right; it will require a *minimum* of two
> walks through the tree to get everything right.
>
> Victor
> --
> Victor J. Orlikowski
> ======================
> v.j.orlikowski@gte.net
> orlikowski@apache.org
> vjo@us.ibm.com
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Config files, main loop, and logging
Posted by "Victor J. Orlikowski" <v....@gte.net>.
<snip>
> No, the intent of EXEC_ON_READ, is to allow modules to have an immediate
> impact on how the config file is read. This is why all of the container
> directives are EXEC_ON_READ. I am not saying that LogLevel fits into that
> category, but lets be accurate about the goal of EXEC_ON_READ.
> We are likely to always require two passes through the tree. The first
> sets everything up, and the second actually starts the server. I see no
> good way around that.
*Sigh*
EXEC_ON_READ is fine and dandy, but we have a problem.
Namely, what is almost needed is to read in the tree, in its entirety,
without performing any sort of walk initially.
Then, we need some form of dependency heirarchy for directives, or at
least a set of classes defining an order for their handling as the
tree is walked for the first time.
(Hrm. Sounds like a tree in which depth of nodes correlates to order
of load....)
For example, if an admin is debugging mod_so, and wants to have the
logging set up to debug from the very start, we shouldn't hamstring
him; least astonishment says it should just work. Meaning, LogLevel is
among the first directives handled, so that the desired messages come
through.
Or maybe this is over-engineering...
However, Ryan is certainly right; it will require a *minimum* of two
walks through the tree to get everything right.
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Config files, main loop, and logging
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Greg Stein wrote:
> Woah, woah woah... the idea was to parse the values into the config tree.
> Parse *once*. We can scan the tree however many times we want, but the
> intent is to parse just one time.
You and I are using different terms for the same thing. When I talk of
parsing the tree, I mean scanning it. I want to read the file into the
tree once, and walk the tree as many times as we need to.
> EXEC_ON_READ *only* exists so that we can load stuff to recognize more
> directives (LoadModule). It shouldn't be used for anything else.
No, the intent of EXEC_ON_READ, is to allow modules to have an immediate
impact on how the config file is read. This is why all of the container
directives are EXEC_ON_READ. I am not saying that LogLevel fits into that
category, but lets be accurate about the goal of EXEC_ON_READ.
> [ it is possible that Ryan meant "scan" when he said "parse", but we should
> be using the right terminology here... ]
Then we need to decide on a terminology. I personally like read the file
into the tree, and walk the tree. I think those are unambiguous.
> So... we want to read/parse once. Scan for Log stuff. Open the logs and
> whatnot. Scan for starting up the server.
>
> IIRC, the current code reads/parses twice (it does the read/scan as a pair).
> That is mostly because we never got a chance to complete the switch over to
> the tree-based scanning, to change main.c, and to see if it continues to
> work properly.
>
> Now... it is still possible that the LoadModule will cause an error to pop
> during the read/parse pass. Similarly, we could get an error during the Log
> scan. In these cases, the server probably needs to dump the errors to
> stderr(?) (dunno for Windows). Dunno about the logic for that, either. I'd
> assume that all code should be calling ap_log_* and we just "do the right
> thing" based on the state of the system.
>
We are likely to always require two passes through the tree. The first
sets everything up, and the second actually starts the server. I see no
good way around that.
Ryan
> Cheers,
> -g
>
> On Wed, Apr 11, 2001 at 01:40:52PM -0700, rbb@covalent.net wrote:
> >
> > Okay, so there are a couple of fixes that could be implemented.
> >
> > The config file needs to be parsed twice for exactly this reason. The
> > first time through, we don't have the log level, we don't have the log
> > files, etc. There is a large set of information that we just haven't read
> > from the config file yet.
> >
> > The idea is to read the config file once, into the config tree, and then
> > parse it once to get the base information, stuff like, ErrorLog, LogLevel,
> > etc.
> >
> > Then parse it a second time, to actually run through the real config and
> > start the server.
> >
> > The first potential fix, is to keep the dual parse that we currently have.
> >
> > The second is to make more directives EXEC_ON_READ. This flag basically
> > tells the server to actually implement the directive as soon as it is read
> > from the config file.
> >
> > Just making more directives EXEC_ON_READ is not going to be enough in and
> > of itself, because that continues to mean that order is important in the
> > config file.
> >
> > Ideally, it wouldn't matter when LogLevel is found in the config file, it
> > is set before we try to actually parse the config file. In reality, that
> > doesn't really work, which is why we have to parse twice.
> >
> > You should expect that the first time we load DSO's into the server, they
> > will be loaded quietly, and the debug messages won't be logged until the
> > second time they are loaded. That is how things are expected to work.
> >
> > Ryan
> >
> > On Wed, 11 Apr 2001, Victor J. Orlikowski wrote:
> >
> > > Hi all,
> > >
> > > Running into a problem, in the debugging of one of my favorite things,
> > > mod_so. While doing some debugging, I had set LogLevel in my conf file
> > > to debug, but got no messages about loading DSOs. So I dug a little
> > > deeper...
> > > Basically, in the main loop we do an ap_read_config(), which does an
> > > init_server_config(). This, among other things, sets the server
> > > loglevel to DEFAULT_LOGLEVEL, which is equivalent to APLOG_WARN.
> > > Afterwards, we do ap_build_config(), which works on the directives for
> > > mod_so and other modules.
> > > Now, if a DSO is loaded successfully, mod_so tries to log this at the
> > > APLOG_DEBUG level. It does so by calling ap_log_perror(), though it
> > > really should do it by calling ap_log_error(). No matter. Under the
> > > covers, those two both call log_error_core(). Now, the server loglevel
> > > has not been changed from DEFAULT_LOGLEVEL, and so, the following
> > > checks cause the debug messages from mod_so (and any other modules
> > > that do debug logging as the initialize from directive) to never
> > > happen:
> > >
> > > if (s == NULL) {
> > > /*
> > > * If we are doing stderr logging (startup), don't log messages that are
> > > * above the default server log level unless it is a startup/shutdown
> > > * notice
> > > */
> > > if ((level_and_mask != APLOG_NOTICE) &&
> > > (level_and_mask > DEFAULT_LOGLEVEL))
> > > return;
> > > logf = stderr_log;
> > > }
> > > else if (s->error_log) {
> > > /*
> > > * If we are doing normal logging, don't log messages that are
> > > * above the server log level unless it is a startup/shutdown notice
> > > */
> > > if ((level_and_mask != APLOG_NOTICE) &&
> > > (level_and_mask > s->loglevel))
> > > return;
> > > logf = s->error_log;
> > > }
> > >
> > > We see that, using ap_log_perror() (which sets s to NULL), any
> > > messages that are logged at a lesser severity than APLOG_WARN are
> > > discarded. With ap_log_error(), the server loglevel determines the
> > > severity of message permitted - unfortunately, this isn't set to the
> > > value specified in the conf file until ap_process_config_tree() is
> > > called, 2 lines after ap_read_config() in main(). Hence, any debug
> > > messages from modules like mod_so are discarded.
> > >
> > > In my opinion, the correct way to fix this is to have the server
> > > fields filled in, prior to acting upon module config options.
> > > However, I'd like to kill two birds with one stone, and get rid of the
> > > config re-read that occurs in main(). Which leads me to ask what
> > > brought the necessity to load the config file a second time (i.e. why
> > > is there a need to wait for the log files to "settle").
> > >
> > > Congrats if you got this far,
> > >
> > > Victor
> > > --
> > > Victor J. Orlikowski
> > > ======================
> > > v.j.orlikowski@gte.net
> > > orlikowski@apache.org
> > > vjo@us.ibm.com
> > >
> > >
> >
> >
> > _______________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Config files, main loop, and logging
Posted by Greg Stein <gs...@lyra.org>.
Woah, woah woah... the idea was to parse the values into the config tree.
Parse *once*. We can scan the tree however many times we want, but the
intent is to parse just one time.
EXEC_ON_READ *only* exists so that we can load stuff to recognize more
directives (LoadModule). It shouldn't be used for anything else.
[ it is possible that Ryan meant "scan" when he said "parse", but we should
be using the right terminology here... ]
So... we want to read/parse once. Scan for Log stuff. Open the logs and
whatnot. Scan for starting up the server.
IIRC, the current code reads/parses twice (it does the read/scan as a pair).
That is mostly because we never got a chance to complete the switch over to
the tree-based scanning, to change main.c, and to see if it continues to
work properly.
Now... it is still possible that the LoadModule will cause an error to pop
during the read/parse pass. Similarly, we could get an error during the Log
scan. In these cases, the server probably needs to dump the errors to
stderr(?) (dunno for Windows). Dunno about the logic for that, either. I'd
assume that all code should be calling ap_log_* and we just "do the right
thing" based on the state of the system.
Cheers,
-g
On Wed, Apr 11, 2001 at 01:40:52PM -0700, rbb@covalent.net wrote:
>
> Okay, so there are a couple of fixes that could be implemented.
>
> The config file needs to be parsed twice for exactly this reason. The
> first time through, we don't have the log level, we don't have the log
> files, etc. There is a large set of information that we just haven't read
> from the config file yet.
>
> The idea is to read the config file once, into the config tree, and then
> parse it once to get the base information, stuff like, ErrorLog, LogLevel,
> etc.
>
> Then parse it a second time, to actually run through the real config and
> start the server.
>
> The first potential fix, is to keep the dual parse that we currently have.
>
> The second is to make more directives EXEC_ON_READ. This flag basically
> tells the server to actually implement the directive as soon as it is read
> from the config file.
>
> Just making more directives EXEC_ON_READ is not going to be enough in and
> of itself, because that continues to mean that order is important in the
> config file.
>
> Ideally, it wouldn't matter when LogLevel is found in the config file, it
> is set before we try to actually parse the config file. In reality, that
> doesn't really work, which is why we have to parse twice.
>
> You should expect that the first time we load DSO's into the server, they
> will be loaded quietly, and the debug messages won't be logged until the
> second time they are loaded. That is how things are expected to work.
>
> Ryan
>
> On Wed, 11 Apr 2001, Victor J. Orlikowski wrote:
>
> > Hi all,
> >
> > Running into a problem, in the debugging of one of my favorite things,
> > mod_so. While doing some debugging, I had set LogLevel in my conf file
> > to debug, but got no messages about loading DSOs. So I dug a little
> > deeper...
> > Basically, in the main loop we do an ap_read_config(), which does an
> > init_server_config(). This, among other things, sets the server
> > loglevel to DEFAULT_LOGLEVEL, which is equivalent to APLOG_WARN.
> > Afterwards, we do ap_build_config(), which works on the directives for
> > mod_so and other modules.
> > Now, if a DSO is loaded successfully, mod_so tries to log this at the
> > APLOG_DEBUG level. It does so by calling ap_log_perror(), though it
> > really should do it by calling ap_log_error(). No matter. Under the
> > covers, those two both call log_error_core(). Now, the server loglevel
> > has not been changed from DEFAULT_LOGLEVEL, and so, the following
> > checks cause the debug messages from mod_so (and any other modules
> > that do debug logging as the initialize from directive) to never
> > happen:
> >
> > if (s == NULL) {
> > /*
> > * If we are doing stderr logging (startup), don't log messages that are
> > * above the default server log level unless it is a startup/shutdown
> > * notice
> > */
> > if ((level_and_mask != APLOG_NOTICE) &&
> > (level_and_mask > DEFAULT_LOGLEVEL))
> > return;
> > logf = stderr_log;
> > }
> > else if (s->error_log) {
> > /*
> > * If we are doing normal logging, don't log messages that are
> > * above the server log level unless it is a startup/shutdown notice
> > */
> > if ((level_and_mask != APLOG_NOTICE) &&
> > (level_and_mask > s->loglevel))
> > return;
> > logf = s->error_log;
> > }
> >
> > We see that, using ap_log_perror() (which sets s to NULL), any
> > messages that are logged at a lesser severity than APLOG_WARN are
> > discarded. With ap_log_error(), the server loglevel determines the
> > severity of message permitted - unfortunately, this isn't set to the
> > value specified in the conf file until ap_process_config_tree() is
> > called, 2 lines after ap_read_config() in main(). Hence, any debug
> > messages from modules like mod_so are discarded.
> >
> > In my opinion, the correct way to fix this is to have the server
> > fields filled in, prior to acting upon module config options.
> > However, I'd like to kill two birds with one stone, and get rid of the
> > config re-read that occurs in main(). Which leads me to ask what
> > brought the necessity to load the config file a second time (i.e. why
> > is there a need to wait for the log files to "settle").
> >
> > Congrats if you got this far,
> >
> > Victor
> > --
> > Victor J. Orlikowski
> > ======================
> > v.j.orlikowski@gte.net
> > orlikowski@apache.org
> > vjo@us.ibm.com
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: Config files, main loop, and logging
Posted by rb...@covalent.net.
Okay, so there are a couple of fixes that could be implemented.
The config file needs to be parsed twice for exactly this reason. The
first time through, we don't have the log level, we don't have the log
files, etc. There is a large set of information that we just haven't read
from the config file yet.
The idea is to read the config file once, into the config tree, and then
parse it once to get the base information, stuff like, ErrorLog, LogLevel,
etc.
Then parse it a second time, to actually run through the real config and
start the server.
The first potential fix, is to keep the dual parse that we currently have.
The second is to make more directives EXEC_ON_READ. This flag basically
tells the server to actually implement the directive as soon as it is read
from the config file.
Just making more directives EXEC_ON_READ is not going to be enough in and
of itself, because that continues to mean that order is important in the
config file.
Ideally, it wouldn't matter when LogLevel is found in the config file, it
is set before we try to actually parse the config file. In reality, that
doesn't really work, which is why we have to parse twice.
You should expect that the first time we load DSO's into the server, they
will be loaded quietly, and the debug messages won't be logged until the
second time they are loaded. That is how things are expected to work.
Ryan
On Wed, 11 Apr 2001, Victor J. Orlikowski wrote:
> Hi all,
>
> Running into a problem, in the debugging of one of my favorite things,
> mod_so. While doing some debugging, I had set LogLevel in my conf file
> to debug, but got no messages about loading DSOs. So I dug a little
> deeper...
> Basically, in the main loop we do an ap_read_config(), which does an
> init_server_config(). This, among other things, sets the server
> loglevel to DEFAULT_LOGLEVEL, which is equivalent to APLOG_WARN.
> Afterwards, we do ap_build_config(), which works on the directives for
> mod_so and other modules.
> Now, if a DSO is loaded successfully, mod_so tries to log this at the
> APLOG_DEBUG level. It does so by calling ap_log_perror(), though it
> really should do it by calling ap_log_error(). No matter. Under the
> covers, those two both call log_error_core(). Now, the server loglevel
> has not been changed from DEFAULT_LOGLEVEL, and so, the following
> checks cause the debug messages from mod_so (and any other modules
> that do debug logging as the initialize from directive) to never
> happen:
>
> if (s == NULL) {
> /*
> * If we are doing stderr logging (startup), don't log messages that are
> * above the default server log level unless it is a startup/shutdown
> * notice
> */
> if ((level_and_mask != APLOG_NOTICE) &&
> (level_and_mask > DEFAULT_LOGLEVEL))
> return;
> logf = stderr_log;
> }
> else if (s->error_log) {
> /*
> * If we are doing normal logging, don't log messages that are
> * above the server log level unless it is a startup/shutdown notice
> */
> if ((level_and_mask != APLOG_NOTICE) &&
> (level_and_mask > s->loglevel))
> return;
> logf = s->error_log;
> }
>
> We see that, using ap_log_perror() (which sets s to NULL), any
> messages that are logged at a lesser severity than APLOG_WARN are
> discarded. With ap_log_error(), the server loglevel determines the
> severity of message permitted - unfortunately, this isn't set to the
> value specified in the conf file until ap_process_config_tree() is
> called, 2 lines after ap_read_config() in main(). Hence, any debug
> messages from modules like mod_so are discarded.
>
> In my opinion, the correct way to fix this is to have the server
> fields filled in, prior to acting upon module config options.
> However, I'd like to kill two birds with one stone, and get rid of the
> config re-read that occurs in main(). Which leads me to ask what
> brought the necessity to load the config file a second time (i.e. why
> is there a need to wait for the log files to "settle").
>
> Congrats if you got this far,
>
> Victor
> --
> Victor J. Orlikowski
> ======================
> v.j.orlikowski@gte.net
> orlikowski@apache.org
> vjo@us.ibm.com
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------