httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dietz, Phil E." <>
Subject RE: adding vhost-specific data to shared error logs
Date Mon, 01 Mar 1999 16:04:37 GMT
I think most users of apache feel that "piped logs" are "some kind of
complex feature that power users need, now how do I get my logs to rotate?"

If pipes are going to be the official way of doing any advanced-logging, I
would suggest that a robust logger process be written and become standard in
the apache package.

rotatelogs is very bare bones to say the least.

The new log process should:
	- let you rotate logs at any interval to any filenames you pass
(file.%Y%m%d%s etc.)
	- let you filter certain messages (in or out) to certain logs
	- let you syslog as well as local log
	- perhaps be able to push the files to a remote server for use by
other parts of the chain (like WebTrends, ADSM backup, etc).
	- auto file cleanup

Hmm can't think of any other features.  Anyone else ?

	-----Original Message-----
	From:	Dean Gaudet []
	Sent:	Monday, March 01, 1999 9:46 AM
	Subject:	Re: adding vhost-specific data to shared error logs

	replying to an old message...

	On Fri, 18 Dec 1998, Aidan Cully wrote:

	> On Wed, Dec 16, 1998 at 04:57:59PM, Dean Gaudet said:
	> > On Tue, 15 Dec 1998, Aidan Cully wrote:
	> > 
	> > > I hate to follow up to myself, but no one else has, and I
really don't
	> > > want to continue wasting my time on this feature if no one
cares enough
	> > > about it to let me know.
	> > > 
	> > > So is this useful to people?  Should I be posting to another
forum, or
	> > > should I file a PR on it?  Should I just forget about this
	> > 
	> > I think it's useful but I haven't had a chance to look at your
	> Groovy, that's all I really needed to hear.  I'll fix the bugs I
	> about, do some testing, and resubmit it.
	> To save time, here's an overview of the patch:
	> Change server_rec->error_log from a FILE* to a log_type_rec*,
	> log_type_rec is defined as follows:
	> struct log_type_rec {
	>     int type;
	>     void *data;
	> };
	> where "data" is type dependant, and type can be one of
	> LOG_TYPE_FILE and LOG_TYPE_SHARE.  For SYSLOG, data is ignored,
	> FILE, data is a FILE*, and for SHARE, data is a pointer to a
	> struct shared_log_rec {
	>     char *string;
	>     log_type_rec *share;
	> };
	> (of course, everything that deals directly with error_log has been
	> modified to expect log_type_rec's, rather than FILE*'s.)
	> To support shared loggers, I added another field to server_rec,
	> (surprisingly) shared_loggers.  shared_loggers is an array of
	> log_type_rec's..  The ap_init_virtual_host function has been
	> to use the same 'shared_loggers' pointer among every host.  The
	> AddLogger configuration checks context, then adds another
	> to this array.  The way it does this is to call a modified
	> "open_error_log" function (called ap_open_one_log) that returns a
	> log_type_rec*, and associates that with a string.  The old
	> open_error_log() has been modified to take the return value of
	> ap_open_one_log() and stick it into server_rec->error_log.
	> When ap_open_one_log() encounters a shared logger declaration, it
	> searches through server_rec->shared_loggers for the appropriate
	> and associates a shared_log_rec* with the associated
	> The log_error_core() function has been made recursive..  When an
	> error_log is SHAREd, it prints the header into a buffer and calls
	> itself again.
	> Hope this is all clear..

	It's not obvious to me why you're putting in this complex data
	Wouldn't it be sufficient to use s->server_name as the "string" in
	much all cases?

	This gets back to my KISS philosophy -- you're putting in all this
	logging gear inside apache when you could easily handle it outside
	in a piped logger.  If what you're really looking for is the ability
	send log messages to both syslog and a file, an external logger can
	that no problem.  As long as the server_name is there as the first
	the logger can probably do what it wants. 

	Oh, except for the dynamic vhost situation, which your proposal
	handle either. 


View raw message