httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Config files, main loop, and logging
Date Wed, 11 Apr 2001 20:40:52 GMT

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,

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.


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
> ======================

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message