From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fabio M. Di Nitto <fdinitto@redhat.com>
Date: Thu, 30 Oct 2008 19:20:21 +0100 (CET)
Subject: [Cluster-devel] cluster/logging settings
In-Reply-To: <20081030171736.GC11488@redhat.com>
References: <20081030171736.GC11488@redhat.com>
Message-ID: <Pine.LNX.4.64.0810301903070.2932@trider-g7>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Thu, 30 Oct 2008, David Teigland wrote:

> The new logging section in cluster.conf has the following settings:
> to_stderr
> to_syslog
> to_file
> syslog_facilty
> syslog_level
> logfile
> debug
>
> Here is my interpretation of how they all work:
>
> a,b,c,x,y,z are "connections" that are all *controlled independently*
> a is always on
> b is always on
> c is connected if debug=on
> x is connected if to_stderr=yes
> y is connected if to_syslog=yes
> z is connected if to_file=yes
>
> sources                    destinations  (destination-specific options)
>
> error --a--|               |--x-- stderr
> warn  --b--|---------------|--y-- syslog (syslog_facility, syslog_level)
> debug --c--|               |--z-- file   (logfile)
>
>
> syslog_facility and syslog_level settings are only passed to syslog and do
> not effect connections in this picture at all.  Similarly, logfile is only
> relevant to the file output, and does not effect any connections.
>
> So, a,b,c can all be turned on, and if y is enabled, then syslog can be
> tuned to filter some of them out.  There's no way to selectively filter
> things out of file or stderr; if x or z are turned on, they will let
> everything pass that comes down the pipe (a,b,c).

let's assume this:

logt_print(LOG_CRIT, "critblabla\n");
logt_print(LOG_INFO, "infoblabla\n");
if(debug)
   logt_print(LOG_DEBUG, "debugblabla\n");

If I set log_level to LOG_INFO, I do expect to see both critblabla and 
infoblabla on all selected outputs.

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.

Now, clearly this is only my expectation and that's how I wrote 
ccs_read_logging to act.

Probably what are mixing up here are:
- LOG_DEBUG for print operation != LOG_DEBUG for syslog.
- debug=on != LOG_DEBUG.

I don't have any objections to roll back and make debug=on different from 
priority=LOG_DEBUG as long as all the others agree on what they want (and 
both is not an option ;)).

Fabio

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