httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Config files, main loop, and logging
Date Thu, 12 Apr 2001 00:03:11 GMT
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/

Mime
View raw message