Understanding the logging concept

[Russ Allbery]

Christoph Biedl <cbiedl at CIS.FU-Berlin.DE> writes:
> Russ Allbery wrote...
>> Christoph Biedl <cbiedl at CIS.FU-Berlin.DE> writes:

>>> What's the idea? Are there plans to move _all_ the logging from
>>> immediate syscall to notice/warn/die provided by lib/messages.c and
>>> CURRENT is just in the middle of transistion?

>> Yes.

> Ah, that explains a lot.

> Is there anything that blocks the procedure? As far as I can see it
> basically a huge search&replace operation.

Purely lack of time on my part.  I'm trying to find time to get back to
working on INN, but it's hard.  There are (at least) two major transitions
that CURRENT is in the middle of; that's one of them, but the overview API
conversion is another one and it's harder.

It's not completely search and replace; there are some calls to syslog
that need to be evaluated for whether they're notice, warn, or debug
calls.  But yes, it's mostly straightforward.  If you're interested in
writing patches, I'll try to find time to commit them.

> As I'm planning a different logging system that optionally avoids
> syslog, the usuals handlers appear misnamed. Would you mind to rename
> them from message_log_syslog_* something like "log as defined by
> inn.conf" e.g.  message_log_default_*?

The entire point of those functions is to call syslog.  How a given
program logs is configured by the program by passing in the appropriate
handler functions to message_handlers_*.  (Note that this message library
is also used outside of INN, although that doesn't necessarily mean that
changes to INN need to care about that.)

I have no objections to introducing a *new* set of handlers that the
programs in INN use that make a decision based on some configuration
information and then call one of the other handlers or even do something
entirely different.  Note, however, that changing handlers is used
throughout CURRENT to implement such things as debug mode, quiet mode,
programs that should log via both syslog and stderr or only one of the
two, etc.  Any replacement set of handler functions needs to implement the
same semantics, since the programs in INN have somewhat complex logging
requirements.  (Note that INN-specific handlers that rely on INN-specific
code, like inn.conf, should start with inn_* and be defined in a different
header file than messages.h; the messages library as it stands has no
dependencies on INN-specific code.)

I do want to keep the _syslog_ versions, though, even if they go unused
inside INN, for the use of programs that explicitly want to log via
syslog.

>> Note that you still have to call openlog when using the message.c
>> functions if you're using a message handler that logs to syslog.

> That should be moved into message.c since the actual program doesn't
> need to know how the messages are actually logged.

The message library doesn't know either.  It just takes a set of handlers
and then calls them when appropriate and doesn't know what they're doing
under the hood.  The program is, in the current design, at the only level
of abstraction that knows what logging methods are being used and
therefore knows whether or not to call openlog.

Now, if you introduced a new set of log handlers, I could see also adding
an initialization function that takes a few parameters indicating the
style of logging that you want to set up and that calls openlog if
appropriate.

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

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.