httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Config files, main loop, and logging
Date Thu, 12 Apr 2001 00:20:50 GMT
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
-------------------------------------------------------------------------------


Mime
View raw message