httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: Log file and databases
Date Tue, 09 May 1995 13:58:26 GMT

>    Date: Mon, 08 May 1995 14:53:19 -0500
>    From: Randy Terbush <>
>    Naive question warning:
>    Would it not be possible for the children to open a socket back to the
>    parent for logging transactions?
> You don't even need that much --- they could use pipes (as in the NCSA
> 1.4 code, in which children use pipes back to the parent process to
> let it know when they're ready for another transaction).

This requires IPC support?

>    IF this could be done, this would possibly solve some of the current
>    security issues. It would be relativly easy to write the logging
>    modules for different database formats.
> It's certainly true that you can't seek a pipe.  Using a named pipe as
> the logfile, as you suggest below, might be a good way to prototype
> something like this --- you don't have to hack the server code at all.
> Alternatively, I can imagine config file entries like
>    TransferLog "| /etc/xfer_log_maint -mode count -db /var/logs/xfer.dbm"
> Of course, this begs the question of exactly *what* gets sent to this
> process over the pipe.  CLF entries are a start for the xfer_log, but
> they aren't completely satisfactory to anybody, and the error_log is
> at this point completely unstructured.

I played with this a bit more last night and this is the direction I am

It seems that we could leave the basic CLF code unaltered in the server,
and change the xfer_log, etc. to a named pipe. This *should* essentially
be the same as writing to a flat file in terms of server load and allows
some sites to continue using the existing methods.

Different modules could then be written to read from these pipes and do
the right thing.  I envision the following additions to the logging
code to allow the flexibility that we wish for.

An entry in httpd.conf:

<Logfile logs/access_log.pipe>
DATE "%T %d %Y"

<Logfile logs/error_log.pipe>
DATE "%T %d %Y"


These variables are sketchy, I know... but you get the picture.

The logging modules could parse the .conf file and go nuts.

View raw message