On Thu, Oct 30, 2008 at 07:20:21PM +0100, Fabio M. Di Nitto wrote:
> >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.
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.
> 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. 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.)
Under your scheme, syslog_level and debug change each other in confusing
and redundant ways. 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.)
> 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 ;)).
