innd logging conventions

[Russ Allbery]

Todd Olson <tco2 at cornell.edu> writes:

> I don't have much clear headed experience with the logging.  However
> when I want to search through the logs for something it is not always
> easy to do.  It is not always easy to figure out what phrase is unique
> to grep on for a particular issue.

> From this point of view keeping "SERVER" is a good thing.  But if there
> is something else that substitues for this, then fine, let it go.

I think I've decided to keep SERVER, but to dump the LogName stuff in innd
and just put SERVER directly into the messages.  Since this is just for
error messages or general status messages about the entire server, there
doesn't seem to be a reason to keep SERVER as a static string defined
somewhere else (particularly since innreport expects it to always be
either ME or SERVER).  But if someone can think of a reason to have it be
configurable, speak up.

> As for "cant", the advantage of "cant" over "can't" is that it is easier
> to type it on the command line to a grep command.  That dang "'" just
> makes life difficult.

Even more to the point, the bit about being able to web search is even
more important.  I'll keep cant.  But probably only for innd and nnrpd
where the errors are going to syslog; for other programs that print out
errors to stderr and can be run by hand, I think we should use can't, just
to prevent lots of bug reports on the misspellings.

> If there is going to be fiddling with logging, then I think it should be
> done from the point of view of grepping the logs.  Since it is hard to
> grep based on position, care should be taken to ensure that tags don't
> get used for widely different purposes with only word order
> distinguishing them.

Agreed.

> The most flexible design is to have the error conditions be passed
> internally with unique tokens that we will never have to change in the
> future.  Only in the send-to-syslog routine should those tokens be
> translated in to english word.  This way we can tweak the messages
> written to the log for grepping purposes, with out having to go all over
> the code to change a message.  I imagine something like the mac resource
> concept (in concept).  This also leads to better documentation of
> possible errors, and to the possibility of nonenglish sites customizing
> them to their language.

That's an interesting idea, although innd is a complete mess from the
perspective of trying to implement that right now.  Interestingly, innfeed
is actually much closer.  Hmm.  Now I understand why James took that
approach.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>