new log bleh

[Dean Gaudet <dg...@arctic.org>]

Interrupted system call?

[Sun Sep 14 21:38:21 1997] [info] 4: Interrupted system call: mod_unique_id.c: 172: mod_unique_id: using ip addr 204.62.130.91
[Sun Sep 14 21:38:22 1997] [debug] 4: Interrupted system call: http_main.c: 2269: vhash: total hashed = 4, avg chain = 0, #default = 0, #name-vhost = 10, chain lengths (count x len): 4x1 252x0
[Sun Sep 14 21:38:22 1997] [info] 4: Interrupted system call: http_main.c: 3367: Apache HTTP Server version: Apache/1.3b1-dev
[Sun Sep 14 21:38:22 1997] [info] 4: Interrupted system call: http_main.c: 3369: Server built: Sun Sep 14 21:33:47 PDT 1997
[Sun Sep 14 21:38:22 1997] [info] 4: Interrupted system call: http_main.c: 3371: Server configured -- resuming normal operations

This is why I really wanted the new log format to not be anything but a
glorified printf wrapper.

I'm using loglevel debug, as can be expected.  But most of what's logged
there is garbage imnsho.  I don't like how the log level modifies the
verbosity ... and I don't see the need for filename/linenumber info.  But
I've complained about that before :)

What do I like?  I like that we have log levels, they've been needed for
a long time.

I suggest the following:

- add logging levels to the existing special functions like log_unixerr
    which is supposed to log errno, then use this when you want the
    errno included.

- remove automatic errno printing in aplog_printf

- remove the numeric errno

- remove the filename/line numbers, make them a #define or something if you
    want... but I guarantee that as soon as we make a release and we
    get reports of an error on a specific line I'll be searching for the
    text, not the line number when a user submits an error report.
    Because our code base will be different than what the user is using.

    I'd really hate it if the existance of file/line becomes a crutch when
    we add new messages in the future -- i.e. that we're not descriptive
    enough in the new messages to distinguish them from other messages
    in the code.

Of those the only one I feel very strong about is the auto errno.

Dean

Re: new log bleh

[Dean Gaudet <dg...@arctic.org>]

On Sun, 14 Sep 1997, Marc Slemko wrote:

> On Sun, 14 Sep 1997, Dean Gaudet wrote:
> 
> > - add logging levels to the existing special functions like log_unixerr
> >     which is supposed to log errno, then use this when you want the
> >     errno included.
> > 
> > - remove automatic errno printing in aplog_printf
> > 
> > - remove the numeric errno
> 
> Keep the numeric errno in the log_unixerr equiv.  There is often 
> no nice way to go from strerror(errno) to errno, and I have seen
> some very obscene translations from errno to text.

Sure.

> > - remove the filename/line numbers, make them a #define or something if you
> >     want... but I guarantee that as soon as we make a release and we
> >     get reports of an error on a specific line I'll be searching for the
> >     text, not the line number when a user submits an error report.
> >     Because our code base will be different than what the user is using.
> > 
> >     I'd really hate it if the existance of file/line becomes a crutch when
> >     we add new messages in the future -- i.e. that we're not descriptive
> >     enough in the new messages to distinguish them from other messages
> >     in the code.
> 
> I kindof like this feature.  Even with a different source base,
> the filename is useful.

Sure, filename only.

Dean

Re: new log bleh

[Marc Slemko <ma...@worldgate.com>]

On Sun, 14 Sep 1997, Dean Gaudet wrote:

> - add logging levels to the existing special functions like log_unixerr
>     which is supposed to log errno, then use this when you want the
>     errno included.
> 
> - remove automatic errno printing in aplog_printf
> 
> - remove the numeric errno

Keep the numeric errno in the log_unixerr equiv.  There is often 
no nice way to go from strerror(errno) to errno, and I have seen
some very obscene translations from errno to text.

> 
> - remove the filename/line numbers, make them a #define or something if you
>     want... but I guarantee that as soon as we make a release and we
>     get reports of an error on a specific line I'll be searching for the
>     text, not the line number when a user submits an error report.
>     Because our code base will be different than what the user is using.
> 
>     I'd really hate it if the existance of file/line becomes a crutch when
>     we add new messages in the future -- i.e. that we're not descriptive
>     enough in the new messages to distinguish them from other messages
>     in the code.

I kindof like this feature.  Even with a different source base,
the filename is useful.