[Cluster-devel] cluster/logging settings

[Fabio M. Di Nitto <fdinitto@redhat.com>]

On Thu, 30 Oct 2008, David Teigland wrote:

>> If I set log_level to LOG_INFO, I do expect to see both critblabla and
>> infoblabla on all selected outputs.
>
> Note that you've said "log_level", but it's actually "syslog_level", which
> might lead people to different conclusions about what the option does.

I meant syslog_level. You are right.

void logt_print(int level, char *fmt, ...)
{
         va_list ap;

         if (level > logt_priority)
                 return;

we send a logt_print(LOG_DEBUG..
but if syslog_level is set to LOG_INFO, that message will not make it 
anywhere, even if debug=on.

>
>> If I set log_level to LOG_DEBUG, I clearly expect to see debugblabla
>> passing throgh as well.
>> (except if filtering to syslog is enabled, but we already agreed on this
>> as required feature so I won't mention it as special case anylonger).
>>
>> I often expect that enabling LOG_DEBUG as priority, it will also enable
>> debugging code in general and viceversa. If I set debug=on, I want to be
>> able to catch LOG_DEBUG automatically, because i assume that most of the
>> LOG_DEBUG is wrapped between if(debug) { } statements. I don't feel the
>> need to set two options to enable full debugging.
>
> You don't need to.  Under my scheme, you set debug=on, and full debugging
> appears in the log file where most people want it, and it doesn't appear
> in syslog where most people wouldn't want it.

Not really.. see below the code snippet...

>  If someone *does* want all
> debugging to appear in syslog, then they set debug=on and
> syslog_level=debug to get it... (and once they see the result, they'll
> change it back, because it's really not nice to see all that in
> /var/log/messages.)

We all agreed on this already that's why we have the 
LOG_MODE_FILTER_DEBUG_FROM_SYSLOG that we should probably make a config 
option in cluster.conf or simply avoid by default.

> Under your scheme, syslog_level and debug change each other in confusing
> and redundant ways.

It's not really confusing.. debug enables LOG_DEBUG and LOG_DEBUG enables 
debug. The only thing that might be confusing is that you need to take 
into account global debug, (sub)system debug setting and priority.

>  By setting debug=on you automatically get all
> debugging in syslog (in addition to the logfile usually), which is not
> where we wanted it...  So we added yet another complication:
> LOG_MODE_FILTER_DEBUG_FROM_SYSLOG, which counteracts the bad effects of
> the debug/syslog_level interaction which we didn't really want in the
> first place.  See how complicated this gets when you have one option
> changing another one, but not quite the way you want, so you add another
> flag to work around the unintended effects of one setting implicitly
> changing another?  It's bad all around: just keep them independent and all
> the pain goes away.
>
> (We wouldn't need FILTER_DEBUG_FROM_SYSLOG in my scheme because you
> control each source and destination point explicitly; you say exactly what
> you want, and get it.)

Unless I am misreading your code:

void logt_print(int level, char *fmt, ...)
{
         va_list ap;

         if (level > logt_priority)
                 return;

we send a logt_print(LOG_DEBUG..
if syslog_level is set to LOG_INFO, that message will not make it
anywhere, even if debug=on.

maybe debug=on should really set syslog_level=LOG_DEBUG and 
LOG_MODE_FILTER_DEBUG_FROM_SYSLOG to make this really happen.

Fabio

--
I'm going to make him an offer he can't refuse.