httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Per module LogLevel configuration
Date Fri, 25 Dec 2009 15:35:41 GMT
On Thu, 24 Dec 2009, Paul Querna wrote:
> On Wed, Dec 23, 2009 at 4:14 AM, Stefan Fritsch <sf@sfritsch.de> wrote:
> An alternative implementation would be something along the lines of
> how reconnoiter does logging:
> <https://labs.omniti.com/trac/reconnoiter/browser/trunk/src/utils/noit_log.h>
>
> This would definitely be a larger rewrite in general for logging, but
> would be much more flexible in the long run, but I have grown fond of
> how reconoiter's logging subsystem has worked.
>
> Most modules would do this in their init function:
>
> dlog = ap_log_stream_find("mod_foo/debug")
> elog = ap_log_stream_find("mod_foo/error")
>
> Where dlog/elog are static globals for that file.  If the logging
> system is disabled for that module, logging in the module is then done
> like this:
>
> apL(dlog, "foo is wrong: %d", bar);

I don't see how this would work well with per vhost log level 
configuration. Any idea?

Also, I want something that can be implemented on 2.4 time scales and 
won't delay the release of 2.4. Maybe we should leave a larger rewrite for 
3.0?

> Our current system only has emerg, alert, crit, error, warn, notice,
> info, debug, but because they are not configurable per-module, they
> are difficult to use effectively, I think in general if we had
> per-module logging, we could easily get by with just critical, error,
> info,  and debug.

mod_ssl currently has three sublevels for log level debug, mod_rewrite has 
six. Unless we keep the special directives like RewriteLogLevel, we need 
more levels, not fewer. But if the consensus is that keeping 
RewriteLogLevel is preferred, I am fine with that, too.

Some granularity below module level would be nice, too. For example: 
ssl.reneg, ssl.require, ssl.session_cache, ...
But this is something that I would leave for 3.0, too.


>> For the implementation I thought of some loglevel vector similar to
>> the construct used by ap_get_module_config. There should then be a
>> ap_get_module_loglevel and the ap_log_*error functions would get the
>> module_index as additional parameter. To make things somewhat source
>> compatible, one could redefine APLOG_MARK to something like
>> __FILE__,__LINE__,GLOBAL, i.e. most modules could be compiled without
>> changes (but would then use the global log level). To add support to a
>> module, something like
>>
>>        #define APLOG_MARK_LDAP __FILE__,__LINE__,ldap_module->module_index
>>
>> and a global search and replace would be enough for most modules (or
>> one could even redefine APLOG_MARK in the module source).
>
> hmm, I'm not sure I really like having to redefine APLOG_MARK in every
> file.. It would be nice if we could build the macro into the module
> declaration perhaps?

Sure. Any idea how to do that in a non-ugly way?

Maybe in httpd.h:

 	#define AP_USE_MODULE_LOG(mod) \
 	static int *ap_log_module_index = &mod->module_index

 	#define AP_LOG_MARK __FILE__,__LINE__,*ap_log_module_index

and then in mod_xyz.c:

 	module AP_MODULE_DECLARE_DATA xyz_module;
         #ifdef AP_USE_MODULE_LOG
 	AP_USE_MODULE_LOG(xyz_module);
         #endif

 	...

 	ap_log_error(AP_LOG_MARK, ...

This would at least compile with 2.2.x, too.
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message