On Sat, 23 Dec 2006, [EMAIL PROTECTED] wrote:
>> Mark Stosberg wrote:
>>> Here's something that could be improved in the documentation. Because
>>> the documentation is currently inconsistent on this point, I'm not sure
>>> how to resolve it myself.
>>>
>>> It looks like "log_level" and "debuglevel" are used interchangeably in
>>> the documentation.
>>>
>>> I think one should be chosen as a standard and the other eradicated.>
We've noticed that if slon(8) is started from /etc/rc, stderr becomes
flooded when debug is set > 1. On systems running multiple instances,
becomes compounded, and can become quite a drag on usability of the
console via an emergency console access medium like a "console server" or
"BMC" console like the Dell DRAC.
The short-term solution is appending "2>&1 > /dev/null" in the RC script.
Wouldn't it hold true by POSIX systems accepted standard that:
* "debug_level" declares which message qualify for visibility (either to
be logged to syslog(3) or send to stderr/stdout)
* "-d or -f" (run in foreground, don't background/daemonize, some
permutation etc.) flag/arguments to slon(8) allow for non-startup-fatal
messages to escape to stderr/stdout (as opposed to the absence of 2>&1 >
/dev/null being appended), which is how it seems is done now)
Otherwise stdout/stderr should be silence on non-fatal errors.
* "log_level" acts as a discriminator / qualifier for routing messages to
syslog(3), either in addition to debug_level or autotonamous there of.
Personally I like the the way Net-SNMP does things (despite the project
itself frequently making me want to go crazy -- 5.4 is nice though)
http://www.die.net/doc/linux/man/man1/snmpcmd.1.html
What they've done is create abstraction between "debugging levels" and
"debug message routing", as seen here:
# -D [Magic Token Syntax] -- Set the debugging level
#
# LOGGING OPTIONS
# The mechanism and destination to use for logging of warning and error
# messages can be controlled by passing various parameters to the -L flag.
#
# -Le
# Log messages to the standard error stream.
# -Lf FILE
# Log messages to the specified file.
# -Lo
# Log messages to the standard output stream.
# -Ls FACILITY
# Log messages via syslog, using the specified facility ('d' for
# LOG_DAEMON, 'u' for LOG_USER, or '0'-'7' for LOG_LOCAL0 through
# LOG_LOCAL7).
#
# There are also "upper case" versions of each of these options, which allow
# the corresponding logging mechanism to be restricted to certain priorities
# of message. Using standard error logging as an example:
#
# -LE pri
# will log messages of priority 'pri' and above to standard error.
# -LE p1-p2
# will log messages with priority between 'p1' and 'p2' (inclusive) to
# standard error.
#
# For -LF and -LS the priority specification comes before the file or
# facility token. The priorities recognised are:
#
# 0 or ! for LOG_EMERG, 1 or a for LOG_ALERT, 2 or c for LOG_CRIT, 3 or
# e for LOG_ERR, 4 or w for LOG_WARNING, 5 or n for LOG_NOTICE, 6 or i for
# LOG_INFO, and 7 or d for LOG_DEBUG.
~BAS
> Yes, you're definitely right about that.
>
>> Yes, you're probably right about that.
>>> Also, there is conflicting information about the what the allowed values
>>> and the default is.
>>>
>>> - in slon_tools.pm "-d2" is hardcoded. This should be an option, either
>>> settable in slon_tools.conf, or on the command line with slon_start.
>
> I think inside slon_tools.conf is the right place for this
>
>>> - mkslonconf.sh says valid values are from 0-4, with 4 being the
>>> default, although the next line indicates maybe the default is 2:
>>>
>>> # Debug log level (higher value ==> more output). Range: [0,4], default
>>> 4
>>> #log_level=2
>>>
>>>
>>> - This page in the admin guide suggests that there are 8 levels of
>>> logging, but they are given strings such as "error". No default is named
>>> There . "debuglevel" and "log_level" are used interchangeably here.
>>> http://www.cbbrowne.com/info/slon.html
>>>
>>> - In slon.c, "debuglevel" is referenced, but the valid values are 1-4,
>>> not 0-4.
>>>
>>
>> Reality, I think, is 1-4.
>
> Reality is -4 thru 4, where the values that may be legitimately set are 0-4.
>
> The negative values are the FATAL thru INFO levels, and we don't give the
> option of evading those messages. I don't think that's wrong.
>
> It's possible that there should be some revisions made to which levels
> various messages are associated; they are fairly comprehensively listed in
> the "loganalysis.html" document.
>
> There might be some "INFO" messages that should be at DEBUG levels (e.g. -
> that therefore could be omitted from logs), and vice-versa.
>
>> Making things more consistent would be a good thing... I have some long
>> train rides that should offer some time to look at that...
>
> The last bit of "getting to Halifax" gave some opportunity for assessment.
> There seem to be some well advisable changes; I will doubtless have
> something to commit on this by New Year.
>
> _______________________________________________
> Slony1-general mailing list
> [email protected]
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>
l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
http://www.spiritual-machines.org/
"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
