On Friday 11 March 2011, Jeff Trawick wrote: > I was hoping that someone who knows something would respond, but > what the hey... > > On Fri, Mar 11, 2011 at 9:27 AM, Eric Covener <[email protected]> wrote: > > server/log.c discards anything higher than WARNING if the > > server_rec is NULL.
FWIW, the WARNING can be changed to something else with the -e command line option. But -e does not allow to set per-module levels. > > But, when adding new traceN messages deep down in modules, > > request/conn/server recs might not be handy. > > > > Is it safe to use extern server_rec* ap_server_conf in random > > modules for trace messages? > > yes Not always. Between destruction of the previous pconf and finishing config parsing, ap_server_conf will usually point to invalid data. But this could be changed by registering a pool cleanup on pconf that sets ap_server_conf to NULL. > > Or should server/log.c know the difference between "still in > > startup" and "stupid module couldn't find a server-rec to pass > > but really wants info in main server errorlog via stderr? > > > > (or, should server/log.c be willing to log anything < WARNING and > > > TRACE1 to stderr via s==NULL? as long as it matches the > > LogLevel > > Something I wondered when fixing some server-rec=NULL issues > recently was whether we should have an especially ugly warning > logged in maintainer mode when APLOG_STARTUP isn't included in the > level flags while server-rec is NULL. > > either-it-is-startup-or-you-pass-server_rec works for me. If we ensured that ap_server_conf is either valid or NULL, then ap_log_error() could do that and modules wouldn't have to care about it. Unless I have missed something, this looks like the better solution to me. If it leads to wrong behaviour, ap_log_error could also use ap_state_query() to check what to do. APLOG_STARTUP only determins if the timestamp/severity-level/module prefix is printed. I would be ok with making that a no-op and letting ap_log_error() decide by itself when httpd is in the startup phase. Cheers, Stefan
