httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Cully <>
Subject Re: adding vhost-specific data to shared error logs
Date Mon, 01 Mar 1999 19:53:31 GMT
On Mon, Mar 01, 1999 at 07:46:20AM, Dean Gaudet said:
> 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 feature?
> > > 
> > > I think it's useful but I haven't had a chance to look at your work... 
> > 
> > Groovy, that's all I really needed to hear.  I'll fix the bugs I know
> > 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*, where
> > 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_SYSLOG,
> > LOG_TYPE_FILE and LOG_TYPE_SHARE.  For SYSLOG, data is ignored, for
> > FILE, data is a FILE*, and for SHARE, data is a pointer to a structure:
> > 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, named
> > (surprisingly) shared_loggers.  shared_loggers is an array of named
> > log_type_rec's..  The ap_init_virtual_host function has been modified
> > to use the same 'shared_loggers' pointer among every host.  The
> > AddLogger configuration checks context, then adds another shared_logger
> > 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 one,
> > and associates a shared_log_rec* with the associated log_type_rec*.
> > 
> > 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 structure. 
> Wouldn't it be sufficient to use s->server_name as the "string" in pretty
> much all cases?

Not quite..  Not unless I also had the external logger know how to parse
the apache config files, and be able to figure out which particular vhost
in the config was associated with the server_name.  If y'all wanted to
externalize the config-parsing bits from src/main/, I might be willing to
go this route.

> This gets back to my KISS philosophy -- you're putting in all this extra
> logging gear inside apache when you could easily handle it outside apache
> in a piped logger.

First, piped loggers don't work for error logs..  Error logs currently
have no way of getting vhost specific data.
Second, I put in the more advanced logging gear with the idea that we'd
eventually be able to support more advanced syslogging..  E.g., be able
to set different log facilities, or different log masks for different
vhosts.  FILE*/No FILE* is not quite enough to do that.

> If what you're really looking for is the ability to
> send log messages to both syslog and a file, an external logger can handle
> that no problem.  As long as the server_name is there as the first field,
> the logger can probably do what it wants. 

That's not what I'm looking for..  I'm trying to (securely) store the
error logs under a vhost's docroot, and owned by the vhost's UID.  I'm
trying to do slightly non-obvious log-splitting for the error-logs,
that's all.

> Oh, except for the dynamic vhost situation, which your proposal doesn't
> handle either. 

Oh..  Hmm..  Well, externalizing the config-parsing as I suggest above,
and using the SERVER_NAME environment variable as the initial string
should work pretty well for dynamic vhosts..  (not that externalizing
the config-parsing is necessary for dynamic vhosts, but it is for what
I want to do.)

Aidan Cully       "I saw Judas carryin' the body/ Of John Wilkes Booth..
Panix Staff        Down there by the train..."         -Johnny Cash

View raw message