Date: Mon, 9 Feb 1998 12:37:09 +1100 (EST)
From: "Ron O'Hara" <rono@pen.sentuny.com.au>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-1.3/src/main http_main.c http_protocol.c 
In-Reply-To: <Pine.LNX.3.96dg4.980208164758.11471Q-100000@twinlark.arctic.org>
Message-ID: <Pine.LNX.3.96.980209122446.15457C-100000@pen.sentuny.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Another $0.02 - log files

There is always a conflict of usage with log files in any product.
An internal middleware product that I was the acrhitect of had this
problem.

loglevel=x  either generated too much junk for normal operation
OR if you changed it down, hid too much info for debugging operational
problems.

The only workaround that came close (and had its own issues) was to
include an internal fifo of log messages (all levels) that had a finite
size (we usually used 500 messages) and was dumped to the real log
whenever a serious fault was triggered.

This meant that normal operations produced very small logs except when a
fault (SIGSEGV or similar) occured. At this point, the fifo was dumped and
we had all the messages leading up to the fault at full debug level. This
is effectively a 'traceback' of the logging that you would have liked to
have but dont normally want unless there is a problem.

SIGUSR? could be allowed to trigger arbitrary dumps of the traceback log.


After we switched to this logging tactic, the operational systems (about
40 mainframes and a few mini's for Australia's Telco) ran with logging at
the most minimal level possible. FYI. The software concerned (TEXAS)
handles some serious volumes of traffic. I haven't been involved in the
project for a few years now, but last I heard it was approaching 300
million transactions pa.


Ron O'Hara


On Sun, 8 Feb 1998, Dean Gaudet wrote:

> On Sun, 8 Feb 1998, Roy T. Fielding wrote:
> 
> > >And I still completely disagree with both you and Chuck, who are the only
> > >two complaining about this... and neither of you have to take the time to
> > >tell users "no ignore that stupid warning" when they open PRs about it. 
> > 
> > That has already been fixed in 1.3b -- warnings are not printed by default.
> > The users that are complaining are still using 1.2.
> 
> Oh give me a break, so many things are turned off by raising the LogLevel
> that this is running blind.  In fact the whole LogLevel thing still hasn't
> been cleaned up imho -- we get worse reports from default 1.3 than we did
> from 1.2.  "worse" in the sense that a lot of useful information is just
> not logged.
> 
> > >This warning/notice/whatever is useless.  It diagnoses a normal situation. 
> > 
> > There is nothing normal about failure to deliver content.  The warning
> > is necessary for sites with audited access files and any server placed
> > in an environment where "browsing" is not the norm.  That is why it
> > is a warning and not an error.
> 
> "audited access files" ?  If anything the error logs are not audited, and
> this is already represented in the access_log by a lower bytes_sent.  I
> don't buy any of this argument. 
> 
> Dean
> 
>