pica1dilly at yahoo
Jun 24, 2008, 4:12 AM
Post #4 of 8
(449 views)
Permalink
|
|
Re: ha_log() as defined in /etc/ha,d/shellfuncs
[In reply to]
|
|
--- On Fri, 6/20/08, Lars Marowsky-Bree <lmb[at]suse.de> wrote:
>> Eventually I end up providing one option with
>> ha_log() "to conform to the standard", regardless
>> of the result returned, and one option without ha_log(),
>> that guarantees the result I want to achieve while
>> improving the reliability and the predictability
>> over time
>
> On the subject of clarity, I have no idea what you're
> refering to here.
I am referring to this snippet of ha_log():
(/etc/ha.d/shellfuncs)
ha_logger -t "${HA_LOGTAG}" "$@"
if [ "$?" -eq "0" ] ; then
return 0 !!! if successful
fi
where, if ha_logger fails then ha_log() attempts to write directly to a logfile and to a debugfile. If ha_logger succeeds, ha_log() completes without writing to the log files.
If there are intermittent network problems, assembling the patches of log written in the syslog managed files, and those patches written in the local logfiles should guarantee maximum fun on a slow day.
As I wrote above, not knowing the intention of the developers regarding ha_log(), I'd rather provide 2 different functions to log, one home-made, and one calling ha_log(), to suit what the user prefers: sticking to the HA standard or retrieving meaningful log information.
>
> For resource agent, I'd recommend ocf_log and not
> ha_log, anyway.
After massaging the priority code a bit, this is what ocf_log() does:
(/usr/lib/ocf/resource.d/heartbeat/.ocf-shellfuncs)
if [ "${__OCF_PRIO}" = "DEBUG" ]; then
ha_debug "${__OCF_PRIO}: $__OCF_MSG"
else
ha_log "${__OCF_PRIO}: $__OCF_MSG"
fi
Which doesn't make such a difference IMHO.
> Linux-HA logging relay (daemon), if you insist on using the
> full name.
Sounds just right to me
>> The fact is though, the component has two parts:
>> ha_logger and ha_logd.
>> If the daemon lacks the disk-writing, it's missing
>> then one of the main functions that characterizes
>> as a "logging" daemon.
>
> The daemon can write to disk too,
I apologize for having not looked in the source. Just in one line, how, what for, and when does the HA logging relay "write to disk" ?
> ... or relay to syslog.
> It's main function is buffering to decouple the HA
> stack from the disk or syslog system.
I'm afraid I don't see the benefit of "buffering" a message that is intended to be written to disk.
I understand though how buffering makes sense with an unreliable syslog that would drop messages.
But if the network is shakey, isn't your buffer written to disk at one point, after running out of non-paged memory ?
Now of course, if your storage itself is somewhere out there in the same network...
> If anything, what I'd like even more to see is
> automatically defaulting to the Linux-HA logging
> relay daemon ;-), and if that's not configured
> explicitly but debuglog and logfile are,
> to auto-feed these to the logging system
> configuration.
>
> Nobody should not be using the logging daemon.
>
> ha_logger is not a "the". It's just ha_logger,
> a command line tool to call, but no RA should
> be calling it directly.
Yes, but then ha_log() really needs to be fixed because some folks like me really like seeing that all log messages be written to local disk first, ***before*** being sent out on that "lossy" network, not only when the network is down or flakey as handled by ha_log() today.
Would you agree that ha_log() should write the local log file and/or debug file first, before calling ha_logger ? This would fulfill the condition that the message be saved once before being sent out on the network.
> Sure. The date should be calculated just once.
> Keep in mind that this is legacy though.
If writing log messages to local log and debug files is to be considered as "legacy", should we understand that for a RA to effectively and correctly write to local files, the RA should handle it by itself and not rely on ha_log() to do it, or even expect doing it in the future ?
> Anybody found to not be using logd should be taken out and educated.
>
Fair enough.
But for 'ha_logger' to replace 'logger', does require 'ha_logger' to support the same log facilities and log priorities as 'logger', just to ensure that out-of-band priority messaging, where it is already implemented with 'logger', is also supported with ha_logger.
So with ha_logger to support a '-p' option similar to logger, this would require to slightly modify ha_log().
Do we keep specifying to ha_log():
- the log facility through HA_LOGFACILITY
- the log priority as the uppercase prefix in the message itself, extending the available prefixes to *all* those support be 'logger' ?
Kind regards
Eric
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
|
